greg smart

I have been working to complete an overdue project this week and have a customer that keeps going back and forth on design elements. This can often be a frustrating time in the design process for both sides in this development equation. In addition to dealing with design issues I have also been trying to communicate with our Project Manager, Graphic Designer, and Content Developer as to how the requested changes impact the the process and ultimately the end product.

I pasted a portion of an email below that I think highlights the struggles and technical challenges web developers face as they try and bring a project to fruition.

Okay, I have finished another round of changes. I just wanted to think out loud with this email, I figured we could approach this as an opportunity to help illuminate some of the issues we struggle with on our side (Development). The client wanted the new images larger, so we have now made them 25% larger. Apparently the client has a large monitor that he runs on a high resolution and keeps asking for changes related to how he is viewing the site. This is beginning to cause some issues that the team should be cognoscente of and we should attempt to educate the client, especially if he requests more changes like these:

1. The Fold - I know that we (web nerds) say this should be a non-issue. On most web pages it is good practice to disregard the fold since monitor resolution varies so widely, this is generally regarded as a print concept that is not necessarily applicable to the web. While I subscribe to this concept I think in this case it is coming to bear. I use a 1024px X 728px monitor resolution and about half of the image rotation is below the fold. This means that the full effect of the home page image rotation will be lost on the majority of the visitors to the site, unless they have an unusually high monitor resolution. What I expect to happen here is that the client will start getting feedback from other decision makers on his team and he will ask us to change it back once again.
2. Image Quality - This is actually a double whammy (#3). I had to compress the images to find a happy medium between page performance and image quality. I don’t want to decrease it further.
3. Page Performance - Image size(s) directly impacts page performance. I have decreased the image sizes as much as I can. I think the page performance is suffering somewhat, but it is always a balancing act.
4. Accessibility - This is closely associated with #3. We spend a lot of our time creating code that is as standards compliant as a site can be while still meeting the requested design criteria. As the page performance decreases so does site accessibility. I would imagine that anyone on a limited-bandwidth internet connection will have some difficulty viewing this site. The images in the rotation are around 500kb/.5MB and they will have to view a partially rendered page until all of the images are downloaded.

Bookmarks:

In a previous post related to a MODx and jQuery photo gallery solution I had described the creations of a MODx snippet to dynamically return the contents of a given directory. As I had suspected in my previous post this solution works well with other document types and, with a few tweaks, is currently being utilized to return unordered lists of documents on some of our larger websites.

The Why

We have many instances in which our end users maintain lists of documents on their sites. This may be a list of meeting minutes, newsletters or even a list of images that may be styled into a photo gallery presentation. While the TinyMCE plugin does a good enough job allowing for content updating and list creation, we felt we could provide a faster, simpler user experience. Now, with the documentMan snippet, the only action needed is to upload the newest document into the appropriate directory and the unordered list is populated instantly with the new document.

The How

In order to take advantage of this functionality you will need to download the documentMan snippet code. Use this code to create a new snippet in MODx. Inside the document there is a example call that will look like [!documentMan? &Location=`FileName` &docSort=`sort`!].

The “Location” variable is intended to describe the directory inside of assets/files in which you would like to return the list of documents. The snippet code can be changed easily enough if you need it to return from the images directory instead of the files directory.

The “docSort” variable can be set to “sort” or “rsort” depending on how you would like your list ordered. You can use “sort” for alphanumeric sorting or “rsort” for reverse alphanumeric sorting. We figured with some consistent naming the list order could be controlled easily enough. I anticipate at some point we will write the code that will allow for items to be sorted by timestamp, but that will be added to our to do list at this stage of the game.

What Else?

As we have been working on this code it has occurred to us that while this is a quick and simple solution, in many instances more may be needed. What we are envisioning is developing a MODx module that will serve as a document filter. This would allow for files to not only be uploaded into the system, but would allow for file naming, tagging, and categorization while being found in the site search. Some of our initial steps in this direction have been promising and we look forward to providing each of these solutions back to the MODx community.

Bookmarks:

I recently came across an article by Erin Kissane, Writing Content that Works for a Living that was worth mentioning. While getting content out of a customer is always a challenge, getting/developing good content can seem all but impossible. Erin lays out some guidelines to help streamline and simplify this portion of the development process:

1. Who is the product for?
   Ask yourself: Can the target audience tell from this copy that we’re speaking to them? Can other people outside our audience tell that we’re NOT speaking to them?
2. What is the product?
   Ask yourself: Have we spelled out, clearly and in simple language, what the product is? Are the nouns as concrete as we can make them?
3. What does the product do for its target user?
   Ask yourself: Have we laid out the product’s primary features and benefits in a clear, concrete way?
4. Why is the product better than the available alternatives?
   Ask yourself: What evidence do we have for those claims? Are we presenting that evidence clearly and without fluffy, empty language that makes us look like we’re boasting?

Bookmarks: