Internal Server Error
what the voices in my head tell me to write
Tuesday, February 19, 2008
When to use programmatic constructs to get around browser failings.
Often when I am developing a page there are things I could add to styling of the page to increase its accessibility or graphic design. Simple things such as highlighting the first paragraph of a section by changing its color or font weight. These can add immensely to the visual impression of a page with little additional work.
In theory that is. CSS provides a simple pseudo-class for the above example :first-child. IE6 doesnt implement it. Now I am left with two realistic alternatives. Either don't include that styling element and reduce the functionality of the design or work out a way to programmatically replicate that functionality in a way that IE6 can understand.
In the :first-child example its might be possible to achieve this if for instance the text for each paragraph is being individually pulled out of a database and looped through in a templating system to create the mark up. All that is necessary is to check if it is the first iteration of the loop and add a class attribute to the <p> tag which will hook into CSS to add the styling.
This is not always possible though. Perhaps the entire text for the page is stored en masse in your CMS system and its inserted into the mark up monolithically. You now cannot add in that class to find the first paragraph using your templating language.
Ok then, now what. Javascript to the rescue. You can run a bit of javascript as the page loads which selects the <div> tag representing the section, loop through its children, test to see if each child element in the DOM is a <p> tag and if its the first child. Thats messy, complex to write and error prone.
So, more javascript to the rescue. If you use a Javascript library such as jQuery which uses CSS selectors to attach actions or functions to elements in the DOM it becomes easy.
$('document').ready(function(){
$('div.section p:first-child').addClass('emphasis');
});
does all the hard work for you.
Of course jQuery code runs perfectly well in IE6 so now you can use CSS selectors which never implemented them in the first place. There is the overhead of loading jQuery (or the library of your choice) but that is offset by caching and the like.
jQuery and its cousins do not just enable developers to create more interactive and engaging user interfaces they also enable designers to create more attractive and therefore engaging designs that will work in a wider range of browsers than ever before.
Labels: IA
Permanent link and Comments posted by Rob Cornelius @ Tuesday, February 19, 2008
Tuesday, January 29, 2008
I found a use for AJAX on a site!
I was ordering some seeds for the garden last night. Both of the suppliers websites I was on had a very handy feature. They had a page which assumed that you had a copy of the print catalog in front of you and therefore had the various product codes etc. On the page was a simple form with around 12 input boxes for entering product codes and the quantity for each one.
This was incredibly speedy, no searching through long listings of varieties of carrots etc to click on the right link. A really good example of integrating traditional paper based systems and e-commerce.
But the one thing it lacked was any immediate feedback on the product code you typed in for each input box. You had to wait until you pressed "add to cart" and check the contents of your cart very carefully to see if you had made a typo entering in your product codes.
With a little bit of ajax you could check the product code when the box looses focus and return a little bit of text or even a picture to show what that code relates to. Less errors, more feedback and better interaction.
Labels: IA
Permanent link and Comments posted by Rob Cornelius @ Tuesday, January 29, 2008
Sunday, May 06, 2007
using card sorting for other things
Rae is doing an OU degree at the moment and she was really struggling with her current assignment. She had a whole bunch of ideas and concepts floating around but couldnt work out the relationships between them in order to write her essay. Obviously this is really frustrating.
So what we did was write every idea and concept on its own post-it note and use a convienient door to stick them on, randomly at first. Then we did something in between a mind mapping exercise and a card sort. First we re-arranged them into clusters of related concepts. Then we arranged them with the most important idea at the top of each cluster. Then we finally arranged the clusters into the order that Rae is going to write about them.
Using spatial organization and chunking the concepts into manageable groups made us both think on how the concepts were related in new ways. We could easily re-arrange things and re-sort them by using the post-it notes.
Rae really liked the way of doing things like this. Its a good mental kick start.
Labels: IA
Permanent link and Comments posted by Rob Cornelius @ Sunday, May 06, 2007
Monday, April 09, 2007
AJAX pros and cons
AJAX is a wonderful technology. It enables web developers to break free of the shackles of having to reload a page every time the user has the tiniest interaction with it. The key word in the previous sentence was “tiniest”. It would be pointless to develop a whole AJAX interface for a web based application were everything was handled asynchronously. It would actually be confusing for the user. Users are now used to that little (and getting smaller with more and better broadband) delay between their action and its consequences. The browser provides them with several visual cues as to what is going on. The throbber throbs, the cursor changes, finally the user sees the page redraw.
These visual cues actually reassure the user. They can see they have done something and something is happening elsewhere as a consequence of their action. If they perform an action and nothing happens at all to tell them that their action is being worked upon they become frustrated. Sooner or later this frustration leads to them doing something that has serious consequences like submitting an order form twice in the time it took for the first AJAX call to be processed or more likely leaving the site and taking their business elsewhere.
The AJAX interface designer has to recognise this problem and try to either work with it or work around it. The classic response is to quickly replace some content with a little count down timer or such like while the actual work gets done and then display the real new content. This works well for most simple content. It provides visual feedback to the user. They know their action will get a response. The users patience is still time limited. No one (apart from flash UI designers) likes sitting looking at a progress bar creep across their screen.
For larger more complex interactions it is probably best to stick with a traditional page reload. That way the user is reassured by the browser that important work is going on. Not some icon that looks sort of like a countdown timer but may be something entirely different.
I think all the good web 2.0 sites recognize this. Flickr uses a lot of AJAX but sensibly restricts it to things that can be quickly updated. Where complex interactions are need such as in its organizr it uses flash. Del.icio.us doesn't use AJAX at all. Digg uses a great deal of AJAX if the user is submitting comments etc but again only for small interactions.
The two areas that seems to work well with lots of AJAX are things like Google Docs and Spreadsheets and its various competitors. I personally think this is because they emulate interfaces and interactions that their users are already very familiar with. Often the interaction is simply typing text. Making something bold is not hard to do quickly. The other is in mapping. Google Maps leads the way here of course and it was many peoples introduction to AJAX. There is something very intuitive about dragging a map around and zooming it. If you could bottle it you could make a fortune. However once again its actually a small interaction at each step. “Move left 2 units” etc.
The one thing that in-experienced designers or managers always want is “drag and drop functionality” Macromedia were doing this from Flash 3 / Dreamweaver 4 onwards. And when did you see a drag and drop shopping cart on a web site? Script.aulico.us and other javascript libraries have drag and drop capabilities which are probably a waste of the developers time to write. Why is this. I personally think drag and drop is beyond a lot of non-expert computer users. (even though it is meant for beginners) I have taught computing for the terrified courses. Its there you get a real feeling for users. Yes you become very cynical and jaded but when you have seen people struggling to manage cut and paste or double clicking you realise that anything more complex is beyond most people who use computers. And its no good thinking that in time the level of ignorance will decrease and skill increase. Think of the developing world for instance.
AJAX is wonderful. It can transform some simple tasks on websites. Don't count on developing an entire AJAX interface and your product being successful though. You can have too much of a good thing essentially.
Labels: IA
Permanent link and Comments posted by Rob Cornelius @ Monday, April 09, 2007
Thursday, January 25, 2007
search revisted
I was looking for some presents for people last night when google turned up a gem etsy.
Just try the different search methods down the left hand menu. Ok so they are flash based but boy are they clever. Searching by colour!
To be honest I don't want to buy anything from the site but its so cool just to play with it.
Permanent link and Comments posted by Rob Cornelius @ Thursday, January 25, 2007
Monday, January 15, 2007
this is what I have been talking about
I just read IA as an extension of web design over at digital-web.com. This is what I think is missing with so many aspects of web developement in general. The recognition that there are not really hard boundaries between the various "disciplines" involved in creating a large scale web site.
OK so you might have a DBA creating a schema who can't write a line of HTML and doesn't want to but they still have to be aware that users of the site and therefore the database will be expecting data in a certain format and also they may well be generating data in various formats too.
But in the realm of actually putting stuff on the screen there are a large number of different roles that contribute. Engineers writing the middleware, graphic designers, IAs, IDs, and humble web monkeys writing the html and css. All of them tend to have different terminologies and jargon for exactly the same things. An engineer will use a language like UML to describe something that an IA uses a wireframe and a html developer uses a bunch of markup and css.
The article is written by an IA so the writer sees IAs at the center of web development and everyone should use the same names for things as the IAs deliverables. Fair enough you have to pick one naming system I guess so why not use the IAs instead of the database schemeas or middleware's names for objects. The point of naming your CSS clases to fit wireframes is valid. I hate sites that have classnames like .bigBlueText. Why not use .formHeading or something meaningful
I also saw a recent job posting that supports this view. The IA position was described as being a mediator between the coding and design departments and as a user centered design champion (come back 2001 you job title is here) IAs can perform this role. Its not quite a project manager role but its ensuring that everyone has a common focus. It might not be IA focused or user focused but as long as everyone can sign from the same hymn sheet its going to be a lot easier.
Labels: IA, webdevelopment
Permanent link and Comments posted by Rob Cornelius @ Monday, January 15, 2007
Saturday, January 13, 2007
taking wireframes too literally
Or when to just admit something won't fit.
Sometimes you get given some wireframes and page mock-ups that just cant be done. The most annoying sort are ones that look simple but due to the limitations of the technologies your working with you just can't acheive the "layout" in a wireframe.
A lot of people seem to think that a wireframe is a page mock up. To my mind they are two totally different things. A wireframe shows the content that should go on the page. It illustrates groups of content and the relationships between content but it isn't prescriptive in how you implement the layout. A page mock up is one step down from the final HTML. It has nearly all the features of the final page and looks pretty much like how the final page should look.
So why do so many people treat wireframes as mock ups? They get so annoyed if you tell them "It won't work that way".
Of course web developers like to think they can achieve any layout you care to dream up. And pretty much say that sort of stuff regulary. Give them the change to hand code every last bit of code and this is easyish. Once you start working with code that generates code you are hamstrung by the quality of the generated code. If your code generating code writes bad HTML there is nothing you can do about it.
So in this situation even the most carefully crafted page mock up might be impossible.
The moral of the story is you dont know exactly how things will turn out until you try them.
Labels: IA, webdevelopment, wireframes
Permanent link and Comments posted by Rob Cornelius @ Saturday, January 13, 2007
