Kieran Huggins wrote:I start by structuring the information into logical, meaningful markup (xhtml). If you give this any real amount of thought your site will please CSS-less browsers and screen readers alike. No scripts are allowed at this point; the app must function as a series of static pages. This really isn't too much extra work, and it pays big dividends down the road. Also, testing the app at this point is hella simple!
Yes this is a great technique. I think what you are referring to about giving it real thought is achieving semantic mark-up. But I do think that providing a pure sever-side solution for every mixed client-server solution adds about 40% to the overall work (not the 100% that most people think). In some situations, such as intranets and administration sites, that 40% can't be justified because it's far easier and cheaper just to say to the userbase to make sure they have a decent browser with JavaScript enabled.
I was in just such a situation with my last project and I was able to write a near static HTML page, a model layer that responded with JSON and implement all the functionality from there in lovely AJAXy JavaScript.
Next comes the styling. After having a reasonable data layout in xhtml makes a Photoshop mock-up of the pretty version soooo much easier. I generally start by designing my highest traffic pages, handling more abstract layouts later (like the welcome/home page). People often make the mistake of designing the homepage first, then fight to make the actual data pages fit the design of the home page, which is a tad ridiculous, and leads to terrible design "hacks". I've found my method has given me more satisfying results in far less time, I totally recommend at least trying it.... but moving swiftly along
How do you decide what your pages are going to be? Do you use any kind of iterative design process. Most of the experienced developers I talk to recommend two things: Have a prototyping/design phase for each work iteration and do usability tests.
Application prototyping is a recent interest of mine, I'm keen to learn and try all the different methods. There are use cases, paper prototyping, HTML prototyping, Illustrator/photoshop mock-ups and cleverer tools such as
Axure.
For my last project I used paper and then HTML prototyping. I found that HTML was slow but highly representative of the final product whilst paper was incredibly fast but I missed issues that affected the quality of the designs. One such example was a contextual dialogue box which I planned to overlay over the interface. On paper it looked great, I planned for the dialogue to be dismissed by the user clicking anywhere outside it. When I came implement it I realised that dismissing it in this way was very unnatural. Also the dialogue didn't stand out clearly enough and I was worried users would completely miss it. I solved the first issue by adding a cancel button and the second by adding a drop shadow. So although paper was great for 70% of the design decisions I did miss stuff. Despite this I still prefer paper to HTML because the HTML consumed a huge amount of time and the problems with paper should reduce as I get more experienced.
That sheer number of times I reworked the design whilst prototyping was a great indication of how rubbish my first attempt would have been if I was go ahead and implement that straight away. And I don't think that's just because I'm crap. I know the difference between mental and implementation models but it still took quite a few goes to relinquish my normal thinking.
Towards the end of the project I watched the users try the application out. I noticed a couple of issues immediately. Initially the user didn't understand the relationship between the "list of existing items" and the "currently selected item" panes which underpinned the entire app. The solution involved 15 minutes of tweaking with CSS (increasing and decreasing spacing here and there and changing colours) but it dramatically improved any new users' initial experience of the app.
Usability testing, as I was doing there, was identifying other problems that were invisible to the designer of the application. The designer approaches using his own application with all the knowledge of how it works. So it's essential to see what's clear without all that initial knowledge.
The book "Designing the Obvious" which I've mentioned before talks about all the techniques I've mentioned and more. Read it!
Next comes the behaviour layer. This should be entirely loaded with a JS include with no inline script.
Absolutely. And for best client-side performance <link rel="stylesheet"/>s should appear as high in the document as possible whilst <script> tags should appear as low as possible.
If the browser has JS enabled then the behaviours attach, overriding the default actions with their sexier, ajaxy counterparts. jQuery is designed exactly for this purpose, and if you don't know how much I love it yet, you've been living under a rock. At the bottom of the ocean. On Pluto. Srsly.
JQuery is great. But must admit I'm still mildly intrigued by some of the other frameworks. I guess you'll just have to kick that out of me
So at the end of a build, I've usually only tested in FF & IE6, and 99% of the time it works and displays flawlessly in Safari and Opera.
Wow that's a very high percentage. I don't usually get as lucky as that.
Do I bother checking? Most of the time, but again: I'm kinda lazy about it. Sane CSS almost guarantees compatibility on the style side, and jQuery is also cross-browser. Besides, at the end of the day the app will work with both CSS and JS turned off. So I feel satisfied, and I have yet to hear anyone complain.
I've experienced situations where code written in JQuery wouldn't work in Opera, I never did find the cause of that issue. Perhaps it was just a freak occurrence. I don't operate on assumptions that things will work first time, I think it's wise to expect problems, sometimes big ones.
If you need to do anything really fancy (for more advanced apps and/or intranets) I would just build a client quickly in XULRunner and have people download it & run locally. This guarantees both the flavour and the version of the rendering engine, and also gives you access to some sweet XUL elements.
Cheat!