Posted by Dan Eastwell
Tue, 11 Nov 2008 21:00:00 GMT
A quick example of a CSS style guide - I've been reading about unit testing for jQuery and wonder if an analagous approach could be used on a CSS system.
Probably not, but a style guide featuring every type of box, unit, module and typographic style on the site can quickly allow you to not only see if any changes you make have knock-on or regression errors, but allow you to see what your styles imply.
What do I mean? Well, if you have a particular form style, a style guide should have all form elements shown, even if they appear nowhere on your site - eventually, they will.
If you have a module style, what will it look like at different widths, and in combination with other similar boxes (even if you're building a fluid layout)? A style guide will help you find out and troubleshoot.
I've written about CSS systems analysis, and am happy to find a kindred spirit in Natalie Downe in her article, which covers not only CSS systems analysis, but also the concept of css style guides in any documentation handover.
Posted in CSS, XHTML, Interface Development | Tags analysis, css, guide, style, systems | no comments | no trackbacks
Posted by Dan Eastwell
Thu, 26 Jun 2008 15:12:00 GMT
http://www.hashtags.org/tag/interesting2008/
This is an aggregation of everything on the web tagged '#interesting2008', which was the conference I went to the other day.
Now *that's* web 2.0. You can keep your astroturfed social networks...
Posted in The Web | Tags hashtags, interesting2008, tags, the, web | no comments | no trackbacks
Posted by Dan Eastwell
Wed, 21 May 2008 12:15:00 GMT
Simple usability testing as advocated by Jakob Nielsen with five users showed that user testing did not need to be an expensive procedure; products such as Morae allow 'usability labs' to be constructed from two laptops and a webcam.
This has made Usability Testing as practical and almost exclusively necessary part of the building of any interface (e.g. a simple website) or application (e.g. a website with any form of interaction)
Usability practitioners advocate testing throughout the design process, and not just as an afterthought once an application is built - this can be a simple procedure, with the most trying part being organising your five participants, but regular testing days can return rewards beyond optimising an interface for ease of use.
Get feedback
You can fairly quickly get feedback not only on how or whether your site works, but also on your users' general experience of similar sites, or real-world alternatives. How do your users normally find sign-up procedures? Are they worthwhile? Do they have trouble with so many passwords? Do they like newsletters? Are they familiar with RSS? And so on...
Incremental testing on rollouts
37 signals paved the way with progressive rollouts and testing constantly through this process allows you to fine tune your application. The danger of course is knee-jerk redesigns every time a user misses a button.
Get Evangelists
People will have volunteered for your user testing, especially if you've advertised through Craiglists or Gumtree, and you reimburse people for their time. Your test subjects will probably see this as something of a fun day out and should by the end of it be in a good mood. People love being asked their opinion, and enjoy being part of the process.
Regular testing will mean you have a constant stream of users who have not only seen your site, but have seen you and know you are keen to get things right. This will mean they're pretty likely to tell people about their fun day out and the nice people there. This can only be a good thing...
Contact with clients and creating superusers
In the same way a telephone call is better than an email, regular face-to-face meetings with your user base can lead to a positive reflection on your app/site.
Your users will be more forgiving of any future problems if they know that you're the kind of people who'll look into it, or probably are already.
Through showing people how your site works, possibly in much greater detail than they would find coming to it cold, you also get the equivalent of old school software 'training days', and a set of users who should end up knowing the workings of your site fairly well and, at best, are able to pass this knowledge on.
Regular testing, regular meetings
With all this in mind, it's probably worth conducting testing days even if you've got no significant changes to make to your site.
If you keep a database of past testees and those that you didn't have time for, you have the ability to keep in constant 'real-world' touch with your user-base.
User testing can be a very positive way of getting to know your end-users, and in a very focussed way - you have:
- A database of possible testers
- A database of people who know your site and can comment on future change
- A set of site evangelists
- Some possible future superusers
Your users:
- Have a more positive view of your site and it's working
- Become more likely to give you feedback normally
- View you not just a faceless frustrationas, but as 'human'.
Posted in Usability, Interface Development, Design, The Web, Interaction design, User Experience | Tags building, client, relationship, testing, usability, user | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 16 May 2008 13:49:07 GMT
I can happily watch Vimeo videos such as the one illustrated below, within my feed reader, google reader
The great thing is, not only is can I watch the embedded flash movie, I also have the other site's interface within my reader, in that I can favourite the video. When I return to the vimeo site, my favourite has been added.
Posted in Usability, The Web | 2 comments | no trackbacks
Posted by Dan Eastwell
Tue, 13 May 2008 09:56:00 GMT
Here's a short presentation on User Centered Design with examples of user experience and information architecture I've worked on.
It's not definitive, but reflects the process I've used in the past - hopefully it might be of some use!
Posted in Usability, Interface Development, Design | Tags architecture, design, experience, information, interaction, ucd, usability, user, wireframes, wireframing | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 10 May 2008 12:00:00 GMT
James: question for you
what is a wireframe?
Me: well, there, good question
a wireframe is essentially a prototype
it can take many forms
I will provide you with examples
sent at 2:55 pm on wednesday
A set of blueprints for a website made in excel will do for a wireframe
as will something jazzy like this prototype http://test2.danieleastwell.co.uk/scholastic/index.html
you will note the grey areas for unknown content etc and the fact it is mostly static.
however, you could do exactly the same thing with just layout css, rather than anything better
or you could do it all on paper
sent at 3:00 pm on wednesday
James: ah I see
so its a static html version of a dynamic site
Me: not necessarily
it could have no styling
or not be in html
James: so its quite a vague term then
Me: yeah, just like 'prototype'
it could be a set of visio or excel files
I like to prototype in html and css as I find it easy, but I find that I also need some design styleguides
the draw back to doing it that way is you get stuck in the 'how' and don't concentrate on the 'what it does'
I prefer paper.
it's a lot quicker and you don't mind making revisions
James: yeah I tend to plan stuff on paper
Me: you can also scan drawings in and plop them in html if you just need to change something on only one bit
sent at 3:06 pm
on wednesday
Me: here's an example of a paper prototype
http://www.youtube.com/watch?v=ppnRQD06ggY
actually, here's a much much better one.
http://www.youtube.com/watch?v=c4-A-9hGn0U
that's genius. you can tell exaclty what the application is going to do, without having to have it built
you could say they used simple video editing instead of html to wireframe it
I suppose also, though that that's a prototype - a wireframe is more formal and static and has details of what each part of the page contains and does
although some people call that a 'functional spec'
sent at 3:10 pm on wednesday
James: its some dude wandering around an office
ah I see
Me: are
you watching the second one?
the 'ciao'?
you really get a feel
for what the app will do.
James: yes
yeah pretty clever
Me: also,
very simple. saves a lot of time in app development to get your
protoypes right.
and in a very skewed
way that vid is a 'wireframe' as it tells you 'what it does'
(not 'how it works' or
'what it will look like')
sent at 3:14 pm
on wednesday
Me: I
might put this chat on my blog. seems like a fairly useful bit of an
introduction...
(to wireframing)
Posted in Usability, Interface Development, Design | Tags architecture, design, documentation, ia, information, interface, ux, wireframing | 2 comments | no trackbacks
Posted by Dan Eastwell
Mon, 18 Feb 2008 12:53:00 GMT
being the modern world, anything that does go wrong automatically comes attached with the thought-bubble, "at least it's something to blog about."
from Flip-flop flyin'
Posted in The Web | no comments | no trackbacks
Posted by Dan Eastwell
Mon, 28 Jan 2008 14:34:00 GMT
Just come across a problem that may occur again - if you're trying to create a button using background images for button tops and bottoms and a span for an icon (for example), then be careful that the 'hand' cursor appears in Internet Explorer (IE), in all latest versions (5.5, 6, 7).
If you have HTML of the form:
<div class="button">
<a href="#"><span>Button text</span></a>
</div>
you might well set the span to display:block in order to have a background image show. In this case, IE will render the default cursor for span, rather than the hand ('pointer') you're expecting
in this case, set the CSS to:
div.button span{
cursor:hand;
}
in your IE only css file (or add cursor:pointer;cursor:hand if you don't filter out Internet Explorer using conditional comments). The hand for the link will now show.
Posted in Browsers, CSS | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 21 Dec 2007 11:06:03 GMT
"We get to drive a few makes of cars (browsers) on the (information) highway. When we want new features, we have to wait for a new model to come out, and recently it feels like Cuba. The top selling car is a 1950’s Chevy."
Dion Almaer in an article about Google Gears
Posted in Browsers | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 07 Dec 2007 17:53:00 GMT
You've spend months on a project, place it on your portfolio with pride. A year or so later, you go back to the site and - horrors - it's completely changed!
I've had that feeling twice recently.
Firstly I was looking for an old image gallery I'd created for the javascript I'd used. When I got to the site all I could see was a 404.
One to change on my portfolio.
This evening I saw an advert on TV for a company I built HTML/CSS templates for, that I was fairly proud of.
Then I did a double-take.
If they've come up with new style product and a new style advert, their site is likely to be rebranded, too. Oh dear.
Leaping to my laptop I looked at their homepage - it's greatly different. Their main landing pages: different. Then I went deeper into the site, to some of their several thousand product and information pages. Very similar. Phew!
This pleases me on a couple of counts - firstly I don't have to take the page from my portfolio, and that the structure, template layouts, palettes for colours and the other CSS systems tricks I'd put into place were still there.
I can only hope the makeover was easy and therefore cheap for the new design team.
The most pleasing thing of all? My name and site still there in the boilerplate in the css files
CSS templates by Dan Eastwell www.thoughtballoon.co.uk
Is it that wrong to have a little pride in your work?
Posted in CSS, Interface Development, Design, The Web | Tags design, websites | 2 comments | no trackbacks
