The other thing to do with that is to take that and look it up in Google scholar and see what has used it as a reference. That might be cool.

Found this over here on Marketing Green:

In his Focus Theory of Normative Conduct, Cialdini et al (1990) suggest that social norms influence acceptable and unacceptable behaviors. He identifies two types of social norms:

• Descriptive norms: “what [other] people typically do”
• Injunctive norms: “what [other] people typically approve or disapprove [of]”

“ Only by aligning descriptive norms…with injunctive norms,” Cialdini et al proposed, “ can one optimize the power of normative appeals.”

I think I may need to find that paper...   

There's a link to a Universally Inaccessible game too. Apparently meant to highlight the problems that may face users to games designers. That really strikes a chord with what I'm hoping to do in my MDA coursework, use Flash to create a game with a series of levels to highlight some of the problems that occur.  

More reading to do, but it's a start!  

So, taking it away from them.

Software agents can be done really badly (like Microsoft's paperclip - the standard illustration of one). There's a paper from the BT laboratories in 1996 (apparently printed in the Knowledge Engineering Review, vol 11, no 3, written by Hyacinth S. Nwana) that I found over here that tries to tie together a lot of the research at that time into agents. One of the key bits for me was that they couldn't define a consistent definition of what an agent is. The idea is that the software does things in the background to remove the effort from you. So something that helps you search by learning what sites interest you and suggesting things in a similar vein.

At some level then maybe a page like iGoogle or netvibes or bloglines, where you collect a set of things for it to 'watch' on your behalf and immediately update could be considered to be a really simple agent - it does take the work away from following feeds, because you only have to look at them when there's something new. But a cleverer system could be to take the feeds you look at, then scan for other feeds that reference them. You can do this yourself by looking at the trackbacks on posts, or search on the content I guess.

Direct manipulation is just that. Everything that needs doing, you do yourself. So rather than let Clippy set up your letter, you decide where you want the address and do the formatting and so on.

I don't think these are necessarily opposing technologies. I think there's a time and a place for both, and actually they could work really well together. If I'm searching for something specific, it might be handy to have a list of links relating to previous stuff and the current search. But don't not do the current search (direct manipulation) in favour of only returning the suggested links. That's self-reinforcing. On the feeds thing, sure, highlight some extra stuff I might find interesting, but don't stop following my selected feeds just because I haven't been particularly interested for a day or so.

As for which technology is better for usability, that's pretty tough. Any system you need to train before it becomes properly useful. It's interesting to me that most blind users don't surf the web for fun, but with a specific purpose. Would they be more likely to surf for fun if the process was fun for them? So if an agent learnt some of their preferences and found relevant other pages quickly and easily for them, would that encourage them to explore further? On the other hand, that kind of learning and altering of what's available could make an interface much less predictable and therefore harder to use, especially if you rely on 'learning' the layout of the screen.

I need to do some more reading on this for the exam, but I'm struggling with my searches. I think that's a side-effect of the word agent now applying to too many things. Looks like Pattie Maes wrote an extremely cited piece in 1994 - "Agents that reduce work and information overload". On the ACM. Maybe I'll have a look at some of the papers that cite it, and read it myself.

It was really interesting trying to decide which buttons (sorry, push switches) to get considering all the needs of our target users. We wanted something that looked ok and provided feedback of its state for all the user groups. There were so many choices! Locking or not, rocker switches or plain push buttons, some light up... Then there was size. Big, little, micro, long toggle switches or low profile rockers... Do we build onto them, or leave them as is? Can we use the colour of the button to signify anything? Do we need different buttons for different functions?

In the end we went for lit up ones (so we can have them lit if they are on, not if they aren't) which locked (giving haptic feedback of the on/off state). We stuck with push switches rather than toggles for the build, and because the buttons only came in three colours we decided to stick with one colour for all four buttons (blue - we liked it). We did think about adding a fifth button for selecting all items (which we could have differentiated by changing the feel - using glitter on it maybe, or cutting the surface somehow) but I don't think we have enough outputs to light that and all the LEDs we want to use. We've gone for nice big buttons that we don't have to build onto, both for the simplicity of the build and how easy it is to find them without looking. I'm not sure we thought about this specifically, but it does make them feel really different to the LEDs on the device.

They look really swanky. Now i just have to work out how to wire them up...

I definitely need to catch up on last Thursday's. I was ill and missed the lecture. It looks like Assignment 2 (the big one... 75% of the course riding on this baby) was revealed. I have to come up with a large Flash executable (well, I could use Director, but there's little point I think) of my choice.

This is where the constraints aiding design comes in. I've got so many different ideas going on. How to select what to do? I've tried drawing up a quick mind-map thing. I think I want to use mostly content I already have. So photos, blogposts etc. But I want to do some designing, and plan with some fonts, colour and layout bits. And then there's the stuff I learnt about at Flash on the Beach. Particles, sound integration...

I need to go back to Chris Orwig's talk maybe, about condensing and focussing, and do some small stuff really well. Make this something I can keep for my portfolio. Get something consistent and good, rather than lots of little bits mishmashed together.

Will have to follow up on the reading for this once I'm well again... 

There are lots of standards around web accessibility in particular. These include the Web Accessibility Initiative set WCAG 1.0, with its three levels of priority. Which I've seen quite a lot of now. Roll on WCAG 2.0, see if they are any better!

PAS 78 is aimed at people who commission websites, and I first came across this at the Geek Girl Dinner i went to where Julie Howell (the author) presented. It's an interesting hole to identify. I'm intigued by it, especially given that I'm working in a world where the requirements are identified by non-developers, and it would be all too easy for accessibility stuff to fall through the (giant) cracks between analysis, design and build. There are a number of reviews of this around too. Frequently by people who had a hand in writing or reviewing it, but there you go!These include Bruce Lawson, out-law.com and the BBC. Amongst many others. This is not law, but it could be helpful to read to stay on the right side of the Disability Discrimination Act.

Section 508 is the US ruling, that applies to all Federal websites. That's interesting in itself. It only applies to Federal websites, not sites in general. I guess one of the problems with making legislation concerning websites in any individual country is always going to be working out whether the website in question actually falls under the juristiction of that country.

There are problems with just following these standards without thought. It is perfectly possible to create a site that totally conforms to the very highest standards but is still totally unusable by anyone. And the automatic site checkers that are available can't check that side of things. I think there might be the corresponding case too, where you have a really great site with some innovative features that make it really easy to use for everyone, but you missed an alt tag or three so you're not 'accessible'. I would be really worried that standards might make it too easy to dismiss the difficulties in making a site truly accessible, and prevent further innovations in the area.

I could do with doing some reading on the pros and cons before the exam!  

The Sonic Finder paper from Gaver was fascinating, because it was written in 1989. It was all about how you can use sound as part of an interface to enhance the experience and help the user. For example, the sound of a file being trashed, or a noise playing once you've hit the icon. He was discussing  how to use sound to give the user some peripheral information that they wouldn't normally get, and give a 'feel' for the item. For example, use a family of noises for a file, with a lower noise indicating a larger file. Dragging noises could change depending on the surface the object is being dragged over, like a dragging over floorboards for empty screen, or over glass for a window.

It was a very literal interpretation, which was interesting. If you think about it, it's not really that obvious that it needs to be that literal. How long would it take to learn that a sound goes with a particular action? I mean, that's how the associations have been formed for the noise of hitting something big vs something small. It also relies quite heavily on the right cultural associations being made. There are enough cultural things associated with presenting information globally (from direction of writing, through to how images are interpreted) without added sounds to the mix. But correspondingly how easy would it be to find sounds that have no cultural implications? And how easy would they be to tell apart?

Earcon is the term for these non-literal noises. And looks like Stephen A. Brewster is the earcon man, although it does look like it's becoming a general term from the search results! (And were defined by Blattner, Sumikawa and Greenberg in 1989) "An evaluation of earcons for use in auditory human-computer interfaces" by S. Brewster,  P. Wright and A. Edwards (ACM, proceedings of CHI '93) has some good bits on why bother using sound as well as visuals for sighted and non-sighted individuals.

The other paper in the reading was McGookin and Brewster on a graph building, published in 2006. This was a paper about teaching blind people to understand and draw graphs. It was apparently awarded the best HCI paper award for 2006, and it's very thorough. Their system used sonic and haptic feedback in a really complementary way to try to represent what was going on on the screen, but apparently while it was streets ahead of current graph-teaching techniques was still subject to a lot of 'off-by-one' errors. Graham's only real criticism of the paper was in the interaction method chosen - a very expensive pen-like device called a phantom, which moves in 3d (when the screen is 2d). The pen metaphor is not going to be particularly familiar to many blind users, and the expense means not many are going to be able to own one. That's yet another factor to consider in this universal usability drive. Devices need to be affordable!

There was some interesting information on using different modes of entry (using a shift key) and whether that was a good idea or not, and if not how do you work around that?

It would be quite interesting to try to come up with a Phidget device to work on the problem... But we've already got one problem to work on!  

First up was "Electronic Sensory Systems for the Visually Impaired" by B. Ando. Published by IEEE.

This had lots of good follow-up leads and overviews on existing handheld systems, and about hearing for the choice of which beep pitches to use etc.

Next I looked into the "Design of Auditory UI for Blind Users" by Hilko Donker, Palle Klante and Peter Gorny. Published by the ACM.

This one was les useful for me, but included some good information about the sound merging. Apparently it's important for the noises to be pleasant for the user, which suggests nice chords of abstract notes would be better than clashing sounds that might more accurately represent the objects we're looking for. Also apparently the human ear is better at distinguishing the position of sounds in a horizontal plane, rather than vertically.

The other interesting bit was how they tested it. They tried to get users to represent their understanding of the screen layout using a set of pins in a cork board, but the mental maps that the blind users produced were completely incomprehensible to them. When they tried the same thing with blindfolded sighted users the maps were more what they were expecting. That implies that  the way the blind users internalised the spatial awareness was very different to the sighted version, and that this isn't necessarily a good way to measure the success of the model. It's pretty interesting in terms of how to represent visual information to people who have no concept of many of the 'standard' visual cues.