October 31, 2003

Beautiful bye bye

Matt Jones' got a lovely farewell image. He's Helsinki bound. Good luck!

Posted by Ant at 09:20 PM | Comments (0) | TrackBack

Fish's grievious bodily harm.

My brother admitted to me yesterday why the fish is really sick... The story goes that he tried to scoop the fish out to clean its tank without using the usual glass dipping technique. Instead, he grabbed the fish in his hand and the little beggar slipped out and suffered a three foot drop to the hard floor. After moments of panic Andrew managed to pick the panicked fish up again, only to repeat the trauma with a second slip knocking the poor thing senseless. It's never been the same since. I fear no amount of peas will fix poor fishy now. Poor fishy.

Posted by Ant at 08:55 PM | Comments (0) | TrackBack

Sick Fish

I'm worried about my brother's fish. It's a bit wierd and lays on the surface on its side, although seemingly not by choice. It's been like that for ages apparently and still seems to have plenty of energy. Andrew, my brother, thinks it's got trapped air and needs to fart. It's all this altitude up here in Boulder I think, which has us all drinking much more water to keep fluids up. Your skin get's really dry up here too.

The vet told Andrew to feed him peas, but he wont eat peas... even when they're broken up and dangled in front of him on bits of cotton. Poor fishy.

Posted by Ant at 12:37 AM | Comments (0) | TrackBack

October 30, 2003

Hiking...

Went for a hike up the Flatirons (part of the Rockies) with Avery (my sister) and Terry (her husband) which was awesome.

It's so beautiful up there. We got a good view of the smoke from the 'wild fires' that were ensuing a small village up there.

More Pictures here

Posted by Ant at 03:30 PM | Comments (0) | TrackBack

October 25, 2003

ForUSE - Conclusions

A few days have passed and I've had time to reflect on the conference now. There were a lot of different angles on design and process covered. Below is a breakdown of the takeaways that were the foremost impressions.

Process
Larry Constantine said it best in the final conversation that was held between the remaining delegates on the last day. "Process is like the training wheels for learning a craft. When one has gained enough experience one knows when to throw it away." Ron Jeffries also had a good way of describing process. "Process is like a Kata, you practice techniques over and over and over to make you learn the art..." Having once studied Karate, the notion of practicing set techniques in different combinations really resonated with me. Through practice, you can draw on your route knowledge of individual techniques and combinations of them, to best solve a problem when faced with it.

The conference presented numerous different processes and ways of 'skinning the cat', but ultimately each set of activities (process) should be tailored to the individual characteristics of the project at hand. You could set down some 'touch-stones' or general guides, but ultimately these have to be vague so as not to be too prescriptive. I've learned a lot more about new techniques and general rules of thumb, so this should be very helpful in laying these 'touch-stones' in the right place.

Usage vs User
"In usage-centered design the focus is on usage - on the work users are doing and the tasks they are trying to accomplish. Users, rather than being the center of attention, are involved in limited and highly focused ways to help designers build tools that will better support the work being done." More on this at foruse.com.

The emphasis of Usage Centred Design is much more on developing software and using notation and language that enables proper dialogue with technical teams. I know this is going to be more powerful than I can imagine right now. The divide between tech and design varies according to the personalities on both sides of the fence. However, through this framework I am confident that we can really begin to communicate properly and constructively. Most technical folk I have known have not been resistant to the tenets of User Centred Design. However seeing the relevance of some of the exercises and techniques has proven a sticking point in the past. I still believe there are appropriate times for applying some of the less quantifyable techniques for gaining context about user goals. However, we need not bog down folk to whom this has no bearing on the job at hand, just as they would not ask me to help write a few lines of code.

The nice thing about Usage Centred Design (U-CD) as a set of techniques and an overall process, is it seems a lot more focused on getting the job done. The areas of User Centred Design (UCD) that have caused me the most trouble with management (and sometimes the team), are those that produce no tangible deliverable for the end product except documentation. U-CD seems not to have the same kind of 'bloat' around it and I think that combined with the best principles of SCRUM wrapped around XP (as illustrated here), it is the kind of process outline that will work flexibly enough to accommodate all projects.

The exact nature of how the agile processes and U-CD mesh is yet to be defined. But the conference had some good examples and success stories, so It looks promising.

Return on Investment (ROI)
XP has the capacity to measure and predict ROI according to chunks of work called 'Stories'. Each story is attributed indexes of value, expense etc and can be prioritised over other stories (according to its overall value) to ensure the optimum return on investment. It is this kind of surety that enables confidentent strategic decisions to be made in the context of a programme of projects.

A Company needs to ascertain what it defines as 'Value' and 'Quality' in order to make decisions about their products' development, based apon these indicators. This body of work should be thorough and consultative with audience and staff. There is also a need for a clear understanding of the business' strategic direction to guide this work. Assessing comparative ROI on any new process means measuring the running costs and revenue of the current and comparing it to that of the new. An accurate assessment of the current running costs and revenue (before the change in methodology) is integral to measuring success.

Breadth and Depth
Breadth and Depth refers to the overall body of work to deliver a product. Depth is exivalent to detail - we delve deeper into the solution. Breadth is more about the big picture such as overall infrastructure and architecture. Agile processes advocate that in each iterative cycle you address both of these. This takes the form of a rule that each cycle must deliver someting tangible like code and also deliver the broader project work too.

Breadth and Depth for design means approaching things differently to what I or most designers I know are used to. However, theoretically it makes sense to design things starting with a sketch, and defining levels of detail iteratively in collaboration with the entire team.

Posted by Ant at 07:42 PM | Comments (0) | TrackBack

10 Steps to instant creativity

Oh, I wish it were that easy... but there may be something in a few of these things. Actually, I know there are. It's basically all the things I was taught at school and Art College, but have somehow lost track of. This 10 point guide to achieving creativity is a part of a larger website dedicated to just being creative in general. Creativity Web - Resources for Creativity and Innovation.

If you dig deep enough, you can also find little gems like this! I got a chuckle out of the design anyway. Perhaps the ideas within aren't so laughable.

Posted by Ant at 01:40 AM | Comments (0) | TrackBack

Nice Image Retrospective

I can't read a word of it, but this guy's blog has got some luscious images from yesteryear on it. http://ostblog.nullserver.net/

Posted by Ant at 01:16 AM | Comments (0) | TrackBack

Media Lab Europe Human Connectedness research group

Media Lab Europe Human Connectedness research group has a plethora of interesting things going on the Social Software front.

Thanks to Matt Webb for passing this nugget on his blog.

Posted by Ant at 12:12 AM | Comments (1) | TrackBack

October 24, 2003

Solar Storms

This BBC NEWS article on Solar Storms made me think... if the sun has these big solar storms and spews hot gasses toward the earth every now and again... does this affect our weather? I mean, surely if it can knock out satellite neworks, its got to be responsible for a bit of a hot day? Or Year? P'raps it doesn't work like that. But if it does, maybe we're blaming the greenhouse effect for something that a solar tempest is responsible for. Prolly not... I'm sure the scientists would've thought of that one.

Posted by Ant at 11:42 PM | Comments (0) | TrackBack

ForUSE - Making Usage More Productive - Lucy Lockwood

Raw Notes... added retrospectively. NB - Usage here refers to Usage Centred Design.

U-CD can dramatically increase productivity of users. We can measure this by how quick people can get in and start, through to error rates.

The primary tenet of U-CD is in understanding Users (Roles), Work (Tasks) and Needs (Tools). The aim is to look at how things are REALLY done and focus on key issues and immediate intentions. What's next?. Look at the purpose of actions in the larger context or workflow. Identify difficulties and how to deal with them.

A Usage Centred Design Approach encourages sound decision making based on realistic assessment of Priorities (business importance + user importance) and tradeoffs. It is business realistic.

Ranking user roles and task cases by frequency of use is key to deciding what is floated to the top level of the User Interface.

Task Case modeling is a powerful tool for Business Process Analysis and redesign. [Say it Sister... This is such a hard one for many to grasp. Design can, does and should inform business models and processes]. Use Task Case modeling to identify 'Technology Steps' or what user actions impact technological solutions.

User ROI. Is a feature worth having if it is too hard to use, too laborious or too hard to get to within an interface?

Design objectives

UI architecture should be easily understood by users, even beginners, after brief exposure or practice. [Learnability if not Usability]. Related information should be gathered about WHEN an interface is used.

WYSIWYN - What you see is what you NEED.

Task cases + User roles are re-usable - e.g. Help topics can be defined by them, test cases, acceptance tests... etc.

Help, whether in context or elsewhere should cover:

  • What is this?
  • How do I?
  • What should I do here?
  • What do you mean?
  • Tell me more!

Most external help entries should explain and support common extensions of:
Explain
..Show Me
....More Info please
......Next|Back

Role Incumbants (this is Lockwood&Constantinese for the characteristics of people performing a certain role. Think Personas). These should bring with them measures of:

  • Proficency - distrubution of skill levels
  • Interaction - charateristic usage patterns
  • Information - communication characteristics

Operational Risks - What are the consequences of error, failur, misuse or delay associated with the application's role? Accuracy, confirmation, error handling, clarity are all to be proportionately well addressed according to operational risk.

Work Environment - Where will the application be used? Noise, Vibration, Lighting etc must all be considered.

Device Constraints - What devices will be used to access the application or information? Input devices (e.g. stylus or keyboard), displays etc must all be considered.

Structure - Be consistent with layout and graphic treatment of elements. Don't represent the same concept differently within the same interface or application.

----

Clustering task cases [This can really help to define what gets done within a sprint or iteration]. Group 'co-operating' task cases together either necessarily or optionally. Cluster toward more efficient interaction and simpler navigation. Visually distance, or seperate cases where co-operation is unlikely.

Conventional use case narratives are fully ordered. Sometimes in the real world these aren't intrinsically fixed. Thus, Flexible ordering should be supported and is preferrable.

Performance metrics: Performance measures directly evaluate actual usage. They can be based on a working system or a prototype. Task completion time, completion rate, percentage complete and correct, help requests, error rates and reworks are all considered when measuring the performance of an interface.

Measurement of an interface should be directly related to design goals.

Measuring the productivity ratio done through the calculation: Unproductive time subtracted from total time, divided by total time. Unproductive time is all time spent not directly working toward the goal (e.g. errors, help requests, delay in interpreting interface etc.)

All measurements of course, are only any good if there is a measure before and after the the change of which measurement is desired.

Posted by Ant at 11:16 PM | Comments (0) | TrackBack

Image Rotation

Random Image Rotation on A List Apart which has also been redesigned.

Thanks to Dan Hill who's blog bought me this nugget.

Posted by Ant at 08:14 PM | Comments (0) | TrackBack

Alice is blogging

Alice, who I was referring to here has got herself a blog. It's aptly called Wonderland. Have a read, she's a funny lass and a bloody bright cookie to boot.

Posted by Ant at 07:47 PM | Comments (0) | TrackBack

Computer Failure

Note to self. Don't try an upgrade an operating system 2 hours before you're due to leave to get on a plane. The laptop seemed to crash half way through the upgrade and had been behaving very strangely since. I decided the easiest thing to do was not to shut it down incase it wouldn't start up again. So finally after 3.5 days of conference noting like a demon, the G3 Powerbook finally crapped out and lost it's operating system. I don't know where, but it's gone la la now. I have more handwritten notes to type up from the last seminar. Will do that tomorrow and take it to the doctor.

I'm in Boulder with my Brother now, and he's got LOTS of computers so I shouldn't be stuck for an internet fix for the next week. Yay!

Posted by Ant at 07:34 AM | Comments (2) | TrackBack

October 22, 2003

ForUSE – Debate: Patterns or Process – Constantine and Lockwood

Debate: Patterns or Process? What works for Usage Centred Design? Lucy Lockwood (process) vs Larry Constantine (patterns).

Patterns are a way to capture the wisdom of many years of design experience. They help to expand and extend the awareness of the experienced designer and aid to save the inexperienced designer. Or are they just a poor, inefficient substitute for well implemented process.

For Patterns Larry Constantine
A pattern is an idea that is useful in one practical context and probably be useful in others. Patterns describe repeated problems along with effective solutions in a standardised useful form. Variations may included name, description of problem, applicability of pattern, solutions, consequences results. Some are just Thou Shalts... or shalt nots.

Welie patterns are some well known and often used patterns. They are a bit "Like, duh" though. Patterns can be from ways to display tables with alternating colours in the rows, to the metaphor of a shopping cart. Good patterns through, capture best practices gained through experience. Patterns describe simple and elegant solutions to problems and capture solutions that have developed and evolved over time. hence they aren't the designs people tend to generate initially,. they reflect untold redesign, as developers have struggled design patterns capture these solutions in a succinct and easily applied form. Design Patterns Addison-Wesley, 1995

Best practice patterns should be Non obvious or even counter intuitive. Broad but specific application. Clearly spell out problem to be solved. Clearly articulate solution and tradeoffs. Exemplify best practices. Basically they are the subtleties within the obvious patterns. The should be based on substantial substantiated patterns.

Against Patterns Lucy Lockwood.
UI design is still at the arts and crafts stage. Early civil engineering and architecture was mostly learned by apprenticeship. They copied what they had seen that worked. Very limited number of 3rd degree wizards. The development of engineering principles and processes allowed for expansion of engineering corps. There is no one size fits all yet, because there just isn't the depth of knowledge to be able to say "This worked here in exactly this situation, so it will work here". Patterns still rely on the '3rd degree wizard' to be able to make best practice. Process allows those who aren't '3rd degree wizards' to work within a framework to achieve best practice.

Practicing designers need help recognising problems and poor design... concrete principles, not cognitive psychology. They need direction for improvements, practical guidance, not canned solutions. There is no such thing as "UI standards". Patterns also only cover 10 - 20% of problems. they are often misapplied. The DO NOT support creativity or innovation.

Who Captures and maintains patterns? A company wants designers to design, not waste time capturing and maintaining patterns and they won't pay for a designer to do this. How do we decide what's a good pattern. It's totally subjective. How do we know that the pattern we have is the best pattern that can be trusted? If a pattern written to be timeless it is too abstract and vague. Description is so general that it doesn't offer specific guidance. Patterns are too tied to current technology and fashion or a particular context.

Where do you find patterns? How do you know which pattern you need? They assume that the designer has analysed the problem well enough to choose a suitable pattern. Patterns can compound a problem that wasn't adequately solved in the inception of the pattern.

[Thought: Competitor analysis is really about gathering patterns...]

Five general rules of usability that patterns are trying to achieve....
Access: make the system usable without help of of instruction.
Efficacy: Don't interfere with those who know it already.
Progression: Facilitate knowledge advancement
Support: Support the real work users are trying to accomplish.
Context: Suit the system to conditions and environment.
Basic Usability principles: Visibility, Feedback, Structure (layout dictated by meaning and use), Reuse (use interface components and behaviors consistently), Tolerance (forgive mistakes), Simplicity.

Posted by Ant at 02:39 PM | Comments (0) | TrackBack

"X Games" Design Off...

DSCF0036.jpgDSCF0037.jpgDSCF0038.jpgDSCF0039.jpgDSCF0040.jpg
Scenes from the "X Games". My team, featured here, came second.

Posted by Ant at 03:51 AM | Comments (0) | TrackBack

ForUSE – The Agile Customer's Toolkit – Tom Poppendieck

Raw Notes...

Most books and publications about XP and agile are very programmer oriented. There's no place for requirements analysis, UI, or interaction design.

Writing effective use cases –

Tools for Customer side practices:
Decision Tools (how to decide what to do)
Role tools (how to organise work and team)
Interface tools.
Story telling and customer tools

Effective collaboration is based on shared
Values Implicit belief system, vision, or mental model about desired business reality or purpose.
Principles – Guiding ideas, insights and rules for deciding.
Practices. – What do Do, Actionable.

Manufacturing metaphors for software development don't work because if you talk to manufacturers and engineers, every time something is built, the process is different and unique. Toyota will stop at every stage of the manufacturing process and test whether it is actually works.

Lean Principles... Tool 1.

Eliminate Waste – Basically, this is just be effective. Weed out the parts of process which are not.
Amplify Learning – This is what iteration is all about. Learning is more important than the code itself.
Decide as late as possible – By waiting, you get more information and feedback
Deliver as fast as possible – if you are going to wait, you have to deliver fast.
Empower the team – agile processes focus on people. Complexity means working together... as effectively as possible. Let the team figure out how to do their job, because they live and breath it and will obviously work out the easiest and most efficient way for them. It will also make them happier.
Build integrity –
See the WHOLE – It is more valuable to measure the effectiveness as a whole, rather than the individuals effectiveness. The team means that everyone is accountable. Rewards should be given to the team, not to individuals within a team.

Concurrent Development... Tool 2

Why are we doing this? What needs to be done? How do we build it? all happen concurrently. Information is done in such a way that you hand over requirements at increasing levels of detail as the project proceeds.

What do we do first? Breadth or Depth? Both. Breadth: Low detail system intent and release and iteration planning. Depth: most important features first. Working app every iteration.

Doing most valuable first is more important than doing most risky... [what is value?]. Build by feature - order by ROI. Defer commitment. Simplicity, feedback, let subsystems and frameworks emerge. Value learning over code. REal customer needs, re-planning and re-factoring are not rework.

Chartering... Tool 4
I don't know why he skipped over tool 3... something about a chair with legs.

Chartering. A team is a community and needs a purpose to exist. Individuals contribute differently. Customers > business goals. Testers > Quality Goals. Interface designer > usage goals. Developers > architecture goals. Analysis > domain goals. A common understanding of purpose is required so all understand the mission. Define success, frame boundaries, facilitate information flow. Align decisions. Mission statement or elevator pitch. Objectives outlining purpose of the project and what it's about. Committed resources. Who defines the success? What is important? What is success? scope? Schedule? defects? resources? You should be able to express all aspects of your mission on one page. If you can't say it concisely, you don't understand it.

XP Practices... Tool 5

Customer Practices: Release and iteration planning. Frequent small releases. Customer tests. Story telling. UI Model. Essential Use Case model...
Developer Practices are the Engine.

Agile Development cycles. Release planning is all about breadth. Iteration planning is a mixture of depth and breadth. Implementation planning is all about depth.

User Stories... Tool 6

Often confused with Use Cases. Stories cover everything the user cares about, both functional and non-functional.Story Card content: Title, One or a few sentences describing what is wanted written by the customer. Developer estimate of relative cost. Sample tests sketched on the back. It's a hand Written index card which has a tactile advantage. Low inhibitions to throw away. Used for sorting, allocating and tracking. The card is not everything though. You needed card, conversation and confirmations. The value is in talking about it, not in documenting it... [hmm, I can see a few probs here from my experience]. Story sizes are determined by implementation effort. They should amount to two to five pair days.

Stories enable FLOW... Velocity can be gauged through being able to assessing history of iterations and assessing burn rate. This means this can establish reliability.

Tom advocates that the end users, UI designers, UC designers, Subject matter experts, Testers and analysts, process and product owners define the right stories and the right tests to then feed requirements to the developers... [This is really quite similar an approach to staggering work that I was writing about a week ago or so]

Domain Language... Tool 7

Find the right words. A glossary of domain language will save a lot of pain and arguments between the team.Effective communication depends on a shared language. EVERYONE must have a common understanding of what is what. A domain should be what the software is about. Domain concepts are what the system shows, knows and remembers. Stories, conversations, customer tests, and code should use domain language. The customer already knows it, though they may not always use it precisely. The language must be rich enough to capture business concepts, rules and relationships. Domain concepts will usually make an appearance on the interface too. It should be directly implemented in code... [lovely gem! It would be worth doing research into the language of the audience too I would say. This would make this even more powerful]. You should iterate this language too. It should be defined in the same way as you would plan doing XP... work on breadth and depth at the same time. Language extends to informal UML, digital photos. class diagrams, interaction diagrams, state diagrams. Make them quick and disposable. [oops... we've been too detailed in this area and spent too much time doing beautiful flow diagrams, thus making it set in stone on some level. They didn't facilitate throwing away and starting again. Makes me think we should come up with a velcro-backed kit or something for making dynamic easily reworkable flow diagrams or something... that would be cool!]

Essential Use Cases... Tool 9
yup, he skipped a whole bunch more. Will ask about that later.

What people use the system to do. Business process workflow. A use case is about a business goal. Steps to reach the goal. User intent steps. System responsibility steps. Use cases implement some part of a workflow. Effective use cases are lean. Most write too much. Use conversation and tests to define details. A use case is a users steps to achieve a goal. A story is a unit of developer work. Don't mix them up.

Alistair Coburn - Writing Effective Use Cases. - buy it. Essential use cases are really brief! like REALLY brief enough to fit on a palm card.

Value to use cases should come from the frequency of use. However, make sure that their not subgoals... as in something that must be done to achieve something else. Prioritise according to value... Now he's going very fast through really good stuff and my brain is tired after a long day. I have slides, so will have to try and fill in the gaps later.

Interface Model... Tool 10

Organise tasks, paper prototype, refine prototype, define tests... eaarrrragghhh!! oh dear, brain has ceased to function all together now. :-(

DSCF0035.jpg
Tom Poppendieck

Posted by Ant at 12:45 AM | Comments (0) | TrackBack

October 21, 2003

ForUSE – Designing for Performance – Helmut Windl

Designing for Performance - Helmut Windl - Siemens (automations and drives)

... Notes are a little more raw than usual, but the content is quite exciting if anything can be gleaned from these scribblings.

Electronic Performance Support Systems (EPSS) with Usage Centred Design (U-CD) N.B. this is NOT the same as User Centred Design (UCD).

EPSS Workflow and tasks are all visible in the interface. software applications that have an explicit goal for supporting work performance and thinking by people who know neither the work nor the software while accomplishing expert

Performance centred design is driven by user performance, whereas U-CD focuses on usage and improved tools supporting task accomplishment. Performance centred design is still a philosophy. There is no explicit process but utilises lots of other processes to inform design.

U-CD
To design fro use you need to understand your users, their work, and their needs.
Users > Roles : Separate user actors from system actors then model roles. User actor play in relation to system
Work > Tasks : Identify Tasks needed to support user roles, cluster tasks by use and meaning, define intentions and responsibilities for each
Needs > Tools and Materials : Model UI contents needed to support task clusters. Derive visual and interaction design from models.

Product definition with product framework, user profiles, features and functions to roles to tasks to contents to implementation model. Also Creative design such as aesthetics. U-CD can be used at any size project from an agile one, to a big bloated process.

Performance Centred
Process simplification, reducing complexity and number of steps etc
Performance Information: All necessary information necessary to perform a task is provided in context.
Decision Support. Helps employee depending on work situation and condition to do the next appropriate steeps.

U-CD task model is currently unable to represent sequences of tasks and conditional branches visually in a model.

To redesign and simplify work flow, we have to capture and understand the clients real work process. This includes events leading up to and after the task itself.

K3 modeling techniques: like contextual design for capturing work process. [must find out more - looks good]. Designed to collect and represent real world work processes in an easy to understand model collaboratively with users. K3-Diagrams of the inspected work processes are drawn during field studies and are generalised to universally valid k3 diagrams that directly feed user role and talk modeling. Foltz, Killich, Wolf, 2000

K3 Notation
Activities represent related tasks supporting a high level goal e.g. cut, copy paste... represented by rounded rectangles. Control flows connect activities to indicate the sequence. Sequences are enclosed in start and end state. [This is quite similar to the way I would advocate modeling flowmaps which are heavily influenced by Jesse James Garret's visual vocab]. "Swim Lanes" [This is a really nice enhancement] allocate activities to personas, user roles or organisational units. Decisions by a user role or person are indicated by a diamond... etc

Much of U-CD doesn't enable flows in a visual way. So melding this with K-3 notation, you can get the Task Flow Map. I'm not going to make notes on this because it's too interesting to be distracted... besides which it's visual and my thousand words won't justify these lovely diagrams!

Exploratory Modeling [my thoughts] – gather questions about a task case or user roles through taking a first attempt based on personas and educated guesses. Then validate these through interviews and contextual enquiry.


DSCF0034.jpg

Posted by Ant at 04:50 PM | Comments (0) | TrackBack

ForUSE - Panel Discussion – Between Extreme and Unified

Between Extreme and Unified: Where are the Users and Usability in Development Processes? - Panel. Ivar Jacombson, Jim Heumann, Ron Jeffries, Jeff Patton, Larry Constantine.

Jeff Says... Interaction designers make great Extreme Programming customers. Don't design up front. Quote "You keep using that word [design]... I do not think that means what you think it means..." You can't design without having an integrated, multidisciplinary design approach. We're talking about very Thick design from surface down to data level. One persons design is another's requirements. Do as much design as is necessary to proceed to that next step in development...

Ron Says... All software development methodologies are based on fear... Kent Beck. Fear from customers, fear from management. Programmers using XP are not predisposed to any particular order of doing things. They will however need to reshuffle things if some requirements are bought to an iteration. One in for one out. You will get things on time.

Jim Says... Usability into Rational Unified Process. Users are in the centre of RUP (based on use cases) Actors in a business use case model to define what the value to use cases to certain actors within the business. Usability comes in at the business level and the interface level. Use Cases need to be at the right level so as not to constrain the creative team and not to let them go too wild. Write the right use cases. Write the use cases right. Write the right system. Write the system right.... nnk...

Ivar says... We essentially agree. To be successful in the Software industry, we must raise the level of competence in our teams. Tools are going to get better and better in time as they develop. We need knowledge as an industry captured as best practices. These are not only best practices for designers but also for managers. We need to develop a process for the complete product life cycle.

Processional March question to Jim and Ivar. Give one example of a project that followed RUP correctly but failed? ... no answer
Same Question to Jeff and Ron about XP. "Everything seemed to keep going fine, customers were literate, process was working well and the quality and usability was high. But the client hadn't listened to their users adequately so the product ultimately failed.

What people are best suited for XP? People who will take on any task and focus on getting a good result for the team. The team works best when the team works together. We want people who are good at what they do and not hide behind a process.

What people are best suited for RUP? There are no specific kind of people that are necessary for RUP. RUP is about establishing a common language so that communication can be facilitated. You want people who are also good at what they do. You also want people who are diverse in skills so that they can empathise with other members of the team.

What kind of project product is XP best at? The best kind is a project that has a finite amount of time with mainly low risk as far as human life is concerned.

What kind are ill suited to XP? Organisations that don't hold the values sympathetic to all agile processes cannot make Agile processes work.

What kind of project is RUP best at? RUP wasn't originally designed as a management process. It was designed to help people know what a good way to do 'x' or practice actually looks like. RUP was designed was made through analysing what was common across lots of projects. RUP is a framework of knowledge, not a specific process. You can apply it to web development to military applications. It can be big or small. It's been going on for 25 years. It is designed to be specialised or customised, not a one size fits all.

To the best of your knowledge, what % of RUP adopters actually do it right, instead of just bought the software and been to classes: About 20%

And XP? The number is increasing, but we would guess a smallish percentage.

What if anything, does XP offer to help the overall visual architecture or organisation of the user interface? Nothing. XP is very much about making good code. it's up to the customer to specify the UI.

And RUP? Through creating a user experience model that is derived through the use cases. Representing flows and flow maps to show how screens fit together. There are specialists on a RUP team dedicated to making a good UI.

Can UML be used as a tool to communicate with XP teams? But of course! One of UML's strengths is aiding in collaboration... XP people say that not many people actually know how to use UML properly. Its a very specific language that is very specific. It is a good tool to know, but you shouldn't rely on it as a communication protocol.

In XP, is the role of Customer responsibility a confusion of expertise? Can a customer specify a good user interface? "Well, it's up to the customer". Jeff says, you can't expect a customer to design something if they're not qualified to do so. It comes back to common sense... use your head. Can your customer specify a user interface? If they can't, then perhaps you need to accommodate them with someone who can realise what they want in the form of an interaction designer.

Posted by Ant at 03:07 PM | Comments (0) | TrackBack

October 20, 2003

ForUSE - Instructive Interaction - Larry Constantine

Instructive Interaction: Innovating without Inundating Users – Larry Constantine.

Raw Notes...

Talking about what users are used to. Based on premise that users can't tell you what they need, but only what they don't like.

Instructive interaction - Help systems as a start. Help systems are often not really very helpful. Finding the help you need takes too long and you lose track of the task at hand. Result is that help is under used and therefore software companies under invest in it because they've figures saying nobody uses it.

Putting help into the interface... or 'instructive interaction' - this is starting to sound a lot like the work we've already done in Single Sign On - where the user interface is self-teaching.

Learning usually requires being told, by being shown or by doing over and over again. Most learning requires repetition and trial and error. Exceptions are 'prepared learning' (single trial learning or Anticipatory learning... the 'oh, I knew that' effect). User encounters a novel or unfamiliar feature, and guesses what it does or how it works, then tries it and is finally rewarded by discovery that they were right. 1) Recognition, 2) Anticipation, 3) Action, 4) Confirmation. [this is kind of like defining 'learnability'] Interface should provide all needed help. Interface has to be 1) explorable 2) intuitable 3) predictable 4) have intrinsic guidance.

Instructive interaction is not about the system trying to do things for the users over the users doing it themselves. It's not about artificial intelligence. It's about making something consistent and learnable like a tool - a hammer. User Agents are also NOT good instructive interaction tools as they're more annoying than useful over time.

Explorable interfaces have no penalties for playing or trying things. Allow users to get out of a situation easily, so that it's forgiving. Consistent, safe cancel and rollback. Infinite level undo and redo is also very good (as in at least 12) even in web applications! (big oops on SSO). Beginners love menus because they allow you to see where you are and how you got there. Nested dialogues are the opposite of this as they obscure views of the previous path.

The user's best guess is probably right [this feels really right to me. I'm always wanting to do lots of 'expectation measuring' within user tests... ask a user what they think will happen by doing a thing, before letting them do a thing]. Windows are like different rooms, you better have a good reason to send a user to another room – Cooper. Contextual help and feedback should be intrinsic to the appearance and behavior of objects, rather than something that's added on to them. It's not so much about MESSAGES, but giving feedback through the behavior of a certain object when manipulated.

Consistency of UI appearance, behavior, and organisation are all important. Behavioral consistency over consistent appearance. Predictability most important of all. Affordances, are as always, very important to learnable interface. Static visual affordances are VERY important, as they're always available to the user even when not actively using. Tooltips, balloon help, starting point highlighted, workflow line (draws the eye from one place to another), etc.

Balloon help - answer 'what is this?' 'what can I do?' 'what should I do?' Cascade screen tips to add more information than just the name of a tool. Link it to the right article in the help section. "Progressive Screen Tips"... make sure you can allow for it to be turned off.

Progressive enabling and disclosure – unobtrusively walk users through a series of actions... wizards don't help skill building because you're still making it into magic rather than teaching the user to do something using the interface.

Anticipatory Action – system tries to guess most common action such as highlighting an option within a dropdown list. Especially for a new concept in a UI you would have the item open/active the first time they come to the interface.

Implicit antecedents... avoid rigid logic or imposed order... don't think like a programmer... skip steps to anticipate what the user really wanted to do (e.g. radio buttons auto select on accompanying value fields being filled out)

Sometimes you need to animate certain interactions in order to have a concept make sense. Sometimes you just can't write out long-hand description of something you can illustrate really clearly with a clear, even stop frame animation.

Sometimes, standard, well established icons and visual elements/interaction idioms can be used in new ways. The key is to test and see whether you've bent the rules too much.

This kind of reminds me of previous lessons in music... "Practice doesn't make perfect... PERFECT practice makes perfect" Learning has to be done right, and anything you can do to aid users in getting it right the first time, the better off your they will be and the quicker they will know your design.

DSCF0033.jpg
Larry Constantine

Posted by Ant at 09:49 PM | Comments (2) | TrackBack

ForUSE - Jeff Patton

Usage Centred design in Extreme programming and agile development environments

Raw Notes...

Agile software development isn't anything new. Books so far (since 1971) have discussed the psychology of teams and programmers within them.


  • Scrum
  • Peopleware
  • Dynamic Systems Development Methodology
  • Crystal Methodologies
  • Feature Driven Development
  • Adaptive Software
  • Extreme Programming

Born of financial need to make things quicker... meeeting of 17 people at Snowbird, Utah, 2001 formed 'the Agile Alliance'. 4 core principles of the Agile Alliance.


  • Individuals and Interactions over Processes and Tools (within the business)
  • Working Software over Comprehensive Documentation
  • Customer Collaboration over Contract Negotiation
  • Responding to change over following a plan.

There are other additional statements are also important and can be found at The Agile Alliance website.

Agile, like UCD is an approach to a method, not a method itself. Releases are composed of Increments which deal with making features. Release Cycle: plan release, feature list, evaluate release. Increment Cycle: Plan increment, determine feature list, evaluate increment. Feature cycle: Design Feature, develop feature, evaluate feature.

Less emphasis on artifacts, up-front design but more on customers and end-user collaboration and emphasis on day to day collaboration within the development team. Incremental improvement resulting in WORKING and USABLE software. Feedback using iterations.

Interesting XP points. Simplicity in design, test driven development, collective ownership, coding standards, System Design Metaphors, Frequent small releases, Customer acceptance testing.

Injecting UCD into XP - Release: Reconcile Roles and Goals with tasks then features. Role and task determine feature priority. Role and Task information drive feature design. Use feature priority and cost to find scope cutting opportunities. Increment: Role and talks information determine bug criticality. Feature: Role and Task information Drive feature design. Test using use cases assuming a user role.

Understanding the Domain. Contextual design work, taking photos of your end users, hear from them and their managers and other stakeholders. All the team needs to be across the end users.

Tactile collaboration tools and techniques - all your typical post-it note jockey stuff. Food, and Kitchen timer is helpful. Means motive and opportunity (as a way to get people involved in collaborative working. Basically, make it easy for them to do so). Make it fun and quick paced.

Accuracy and Detail aren't the same thing. Focus should be on Accuracy to begin with. Detail can come later... [ this really suits my 'Cut but Cut' thoughts ]. A conversation is better than a document. A poster is better than a document (they're like radiators of information - nice metaphor!). Avoid literal UI renderings.

Must get Alistair Cockburn (Humans and Technology inc.) Book.

Use Focal roles and focal task cases to drive priority. Relax standards on the unimportant features. Special attention to quality on quality for focal roles and tasks.

Detailed design comes in where necessary... as in later on. Write essential use cases, build abstract UI prototypes, Render wireframe UI, Validate through testing.

Agile is great because it allows for the mistakes YOU WILL make. The penalties are less because of the iterative nature of the process.

There are problems, but they mainly come from team issues. People not wanting to change or being freaked out by being out of their comfort zone.

Collaboration plan - contract between customer and design/development team.

DSCF0031.jpg
Jeff Patten

Posted by Ant at 07:37 PM | Comments (0) | TrackBack

Hey, It's Ralph

DSCF0030.jpg

Ralph Lord, someone I know from a few lists (UCD and SigIA). He, Andy and I talked about the film industry's 'packet' preparation. How this can be examined for lessons in our process. Particularly the early sketch design phases and ensuring they meet criteria set by business objectives and strategy.

Posted by Ant at 07:01 PM | Comments (0) | TrackBack

ForUSE - Designing for Breakthroughs in User Performance – Gennine Strope

More raw notes...

Case study in Usage Centred Design meets Agile in making management software for nurses.

Brainstorm User Roles
Mapping roles
Brainstorming tasks
Prioritising tasks

Some mistakes made where profiling wasn't thorough enough and goal directed design wasn't thought through well enough. These guys had something like 20 'severity 1' usability flaws still, after 20 sets of user tests. No design lead time, straight into engineering. This is supposed to be selling us on XP and Usage centred design and so far I'm feeling like it's telling us that if you measure success by user comprehension and understanding, this just didn't stack up well. However, she's touting this as having shaved 4-6 hours on training nurses on the old system. But cripes! What must their old system have been like?

Lots of people say small design teams are best... so does she. Basically advocates contextual design. Keep statistics! (good, something new... I was scared there'd be nothing to think about from this) proof of the progress within the business. Return on Investment must be measured for justifying to management.

She's got a 'pocketfull of wisdom!' omigod, that's slightly nauseating... as is the powerpoint sound effects.

Posted by Ant at 04:54 PM | Comments (0) | TrackBack

ForUSE - Keynote Speech - Bill Buxton

These are raw notes...

Initial distraction about two handed design, designs systems for use with both hands. Inventory of skills a particular audience has acquired. EG musicians, painters.

Everyone is bad at making "new products" in the software industry (not n+1 or new releases). To allay this, most companies will buy a new product and make it an n+1. Why are other sectors that maintain high standards of new product able to do this but the software industry can't? Other industries have a design phase in front of engineering for making NEW products. This sits really comfortably with me – drawing a distinction between a NEW product and a n+1 product. N+1 products don't need as much design up front as totally new ones do to ensure it is as good as possible.

I wish people didn't ask questions that are designed to just needle a presenter. There's no point to the question and the answer doesn't help the understanding of the audience. Ken Schwaber said "no questions if they're longer than the answer". I like that rule.

Status quo is engineering to sales. We discussed last night that the design process needs to incorporate the time after launch and factor in post release maintenance, support and version updates.

Film industry example – the PACKAGE before work begins, or "green light" - Stars signed up. Nailed down with contracts FIRST. Script. Production Schedule. Release date and season. Title and campaign. How much will be spent on marketing. Location, Director of photography with photos of the location... etc. Then the decision is made. Lesson in Venture capital pitches - thorough scoping.

Automotive Design example – sketches, clay models, work closely with engineering. Based on a platform (chassis). Engines and Platforms are hugely expensive and are thus reused. The shell and styling are what make the car. End of the design phase has a concept car, that looks like you could drive away in it, but it's all clay! That happens before the 'green light' is given. Feedback from the audience. 'focus groups' are shown the concept car at shows etc to gauge potential success.

Design phase comes before 'green lighting' a project. This includes all projections of marketing potential, cost and acceptance. We need to have a marketing department who understands what we need from them.

Innovation can still come in the engineering phase, but through implementation, not design changes. It is also essential that there are engineers in the initial design team. A lot of car companies are trying to reduce the design phase through a lot more ethnographic research and contextual enquiry.

Essentially, Bill Buxton agrees with Alan Cooper in saying there's no way to design and engineer at the same time and end up with a well designed and successful product.

Criteria Weight increases as a function of time and investment. Criteria meaning the specifications for success. You need to have a 'dashboard' to continue to monitor whether the product is meeting the criteria you initially set. Think Ken Schwabers' geese finding solutions to a set of requirements when migrating. e.g. of Criterion "80% of the functionality to be understood and learned within 5 minutes" "must be able to be used on all platforms" etc.

Personality types: Designers - change in half an hour, innovate and come up with new features all the time. Engineers - totally organised and anal, not likely to try and introduce things at the end of a build...

Posted by Ant at 04:08 PM | Comments (0) | TrackBack

Portsmouth, ForUSE, Jeff Patton

Arrived in Boston last night at about 9.30 and made our way somewhat tortuously to the Hotel in Portsmouth from Boston Airport via running for a coach and then catching a cab from the 'Stoppango' to the Hotel where the conference is to be held. Why are hotels all so much the same? This one feels just slightly tired and in need of a facelift. But basically very comfortable... mustn't grumble and all that.

Woke up this morning at 'Sparrow's Fart' which was about 5 am... then again at six because the assholes in the room before me left the alarm set for that time, then again all morning till I got up. Spent the day exploring portsmouth (see gallery below).


Portsmouth Pictures

The first of the reception gatherings was held in the evening where I met a few people. One of which was Helmut Windl who works for Siemens and is an associate of Constantine & Lockwood who put this conference on. He's been working toward integrating Performance Centred Design and Usage Centred Design. Some of what he's worked toward is a making workflow obvious to the end user through the interface (basic example would be representing the steps in a linear process). He's extended this to forming a hybrid between an object oriented use case and a user task flow to aid in the development process. He also talked about prioritising features against criterias of frequency of use, overall importance (to tasks), and business importance. I was still jet-lagged a bit, so I couldn't really get the most out of what we were discussing. He had more to say. It didn't stick in my head so well.

Helmut did however, pull Jeff Patton over to talk to Lorna Ledden, Andy Scotland and I about what we're here to glean - how to integrate User/Usage Centred Design with agile processes such as XP and Scrum. Jeff has had a lot of experience with this very thing. The first thing he talked about was measuring risk on a project to determine how much design needs to be done before coding should begin. Risk assessment is done through measuring potential revenue loss versus amount of resources that will be building a given product (i.e. potential money lost on final product vs money spent to build it). Risk becomes a function of design lead time.

We also talked about our past experiences with different processes from UCD to XP to SCRUM which was useful in that he had some insights for us about involving all team members but at the right level and time. I think that this confirmed what we knew from experience but still don't have a handle on the fix yet. How do we get that balance right? Jeff suggested he knew of some techniques to get it right, but wasn't able to demonstrate at the time. Might have some supporting info later.

Posted by Ant at 04:35 AM | Comments (1) | TrackBack

October 17, 2003

Kids Interaction Design

Finding Noobie over at CuriousLee. Lovely ideas around interaction design for Children.

That kids, guided by adult experts, can design technologies for the future, was not necessarily what left me most impressed during my tour of the lab. In this organized playland, scientific method accommodates the laughter of children at play to produce tools that offer delight before utility

Thanks Matt!

Posted by Ant at 05:09 PM | Comments (0) | TrackBack

October 16, 2003

The coolest sound-scape software

This is the very coolest sound-scape software I've seen in ages. By Amit Pitaru, it uses a pressure sensitive digitising tablet to make sound on a kinda rotating interface. See the demo here. WOW!

Posted by Ant at 03:39 PM | Comments (1) | TrackBack

Defining priorities for the product requirements backlog

I wouldn't advocate using this in isolation, as I think that you need to filter your requirements through a user benefit vs feasability process first. But, this is very useful for defining which of those get worked on first.

requirements_prioritise.jpg

Posted by Ant at 01:49 PM | Comments (3) | TrackBack

Visual Style History

Lovely pictorial history of visual style using a case study in H.G. Wells War of the Worlds book covers from 1895 - present day.

Thanks to Gideon Bullock for sending me this one.

Posted by Ant at 12:21 PM | Comments (1) | TrackBack

No need for a 'print page' button

Nice tutorial on using xhtml and css to rid us of having to make 'print this page' pages. It can only be a good thing. Going to Print by Eric Meyer.

Posted by Ant at 11:54 AM | Comments (0) | TrackBack

October 15, 2003

Why users shouldn't be at the Centre of Design...

When others don’t buy into doing things the “right” way, they are often dismissed as unenlightened luddites who don’t understand the importance of what we do. Thus, some practitioners develop a UCD inferiority complex–a resentful feeling that we’re not appreciated or understood. Often this results in the practitioner’s return to more comfortable territory–conversations within the UX community about methods or tools, or how engineers or marketing just don’t get it. And that leads us to what might be the biggest drawback of UCD.

From Article entitled Searching for the center of design
featured on Boxes and Arrows

Probably the best summation of my experience with UCD evangelism to date (including, dare I say it, my own).

Posted by Ant at 06:57 PM | Comments (0) | TrackBack

October 14, 2003

Restructures...

Today we were mostly being restructured... again. I think it's about the 8th or 9th in the four years I've been here... two a year. That's a pretty good average.

I wish I could send around the Dilbert comic that was sent around the office today, but can't because of copyright. It gave me comfort to know that this phenomenon is common enough to warrant someone writing a comic strip about it.

At today's 'briefing' it was like the head of the department was reading the results of an ugly management turf-war-cum-cat-fight. But I'm sure nothing like that happened at all and it was all in the best interest of the company... ahem.

Posted by Ant at 09:36 PM | Comments (0) | TrackBack

October 13, 2003

SCRUM

On Friday I attended a SCRUM course given by Ken Schwaber, who's brainchild is the SCRUM process (agile software development). A two day course crammed into one was a little hard to absorb, but nonetheless a great opportunity to pick the man's brains about his process.

OK, here are the basic tennets that I had mostly already grasped.


  • SCRUM is and Iterative process (inspect and adapt) good at isolating teams from 'seagull management'. Each iteration is about 30 days and no one is allowed to come and feed more requirements or changes to existing ones within that window (known as a sprint). This is regulated by the 'Scrum Master'.
  • The team meets every day at a given time and place to discuss three things. Each person reports i) What was achieved yesterday ii) what will be worked on today iii) what obstacles stand in the way of getting this done.
  • Requirements fed to team on a basis of 'Best defined, riskiest and business critical first' meaning, those requirements which are known and whose solutions are clearly understood are prioritised before those less defined. Those features which are deemed to have the most risk and or business value (balance of business benefit and user benefit) are also prioritised higher than those which do not.
  • Focus on Return on Investment.
  • Minimal reporting

Things that I had very much clarified were:
  • SCRUM basically has a premise that you can't just hand over a brief or spec, as this flys in the face of the iterative cycle where a multidisciplinary team cracks on with finding solutions to individual requirements rather than defining whole systems (yes, I was worried here... but I'll explain further, it's not that bad). Basically, Ken used the example of a flock of geese which use an empirical process to find what they need when migrating. Their requirements are that they need somewhere that's warm and has enough food and water for the winter. It doesn't matter where they go, so long as these fundamental requirements are met, the geese are happy.
  • The other revelation was that SCRUM can be used on anything from planning a party to building software. The premise is a tight knit multidisciplinary team. Meaning we have design, production, tech, editorial all working together at the same time solving about the same set of requirements in a sprint as each other... and talking lots. So, this allayed my fears that SCRUM was all about clients talking to technicians and design is left out of the equasion.

So, here's the tricky part. Alan Cooper staunchly argues that you can't design a good system as a set of answers to requirements. You need to be able to specify an entire system and it's dependencies if you are to succeed in making a well-designed system. Now, I agree mostly with this but am willing to experiment with the rigidity of this assertion purely because it just is not economical having your techs sitting around answering your odd question as you spend months designing a system that you're reasonably sure, but not definately sure will work. Or, would I argue, is it a good way to build happy and thus productive teams.

There will always be a need to do some preliminary research up front when we're talking about user research and defining requirements where you can't involve all team members 100%. Just like as a user experience designer, I can't code lines of code when the time comes to that. So ultimately when we divide a project into Understand, Concept and Design phases, it defines time periods where different skillsets are 'at the fore'.

resource_distribution.jpg

So whilst in the understand phase, the best thing to do is to employ techs to do research into technical thing. If we see the research as a requirement just like a feature would be we can start to see where a scrum methodology can be employed. The biggest hurdle is convincing programmers that they're not wasting time by being involved in such 'airy fairy nonsense' such as research.

It's always been in the conceptual development phase that things have become hairy or clouded for me. It just never seems right to try and define a system in a slight vaccume (after all, techs can answer our questions, but they too have to estimate the complexity of things from time to time) and the tech team gets (rightly) pissed off waiting for the design team to give them a spec. Here's a thought. What if we were to design in a series of cuts whereby we define a 'sketch' of the overall system first (based of course on the research we carried out in the understand phase), then start to refine it feature by feature once we had some idea what elements would affect other elements. Thereby actually working side by side with techs to constantly flex and change the implementation according to what was achievable or desirable.

So, probably, and I say probably because I haven't tried this yet, it would look something like this.

UCD_SCRUM_integrated.jpg

Basic prototyping has proven to be the most effective form of documentation for communicating functionality to a technical team. A basic interactive wireframe made using Macromedia Flash speaks 1000 times quicker than a UML use-case which arguably takes about as long to write once you've wireframed it and analysed all the permutations of an interaction element. I see this as the way forward, in combination with some UML elements such as flows for specifying the way a system works and how the interface impacts it.

There's so much more to write here... but it's late and my concentration is failing.

Posted by Ant at 12:01 AM | Comments (2) | TrackBack

October 09, 2003

IDEO Method Cards

Ideo's Method Cards are a cool way to communicate design and IA methods to your team and clients. Similar to the ToolKit I'm trying to develop internally here at The Corporation at the moment.

See Also - The Creative WhackPack for more general creativity tools.

Posted by Ant at 10:28 AM | Comments (0) | TrackBack

Information Architecture - overview

Information Architecture.

This lesson has provided information about various ideas associated with the term "information architecture" and has endeavored to show you how information architecture is closely related to, and embodies most of, the long-standing principles of library and information science.

Posted by Ant at 10:24 AM | Comments (0) | TrackBack

October 08, 2003

A City is a brain, not a computer

Paper entitled The Information Architecture of Cities. By L. Andrew Coward and Nikos A. Salingaros.

"This paper argues that a city works less like an electronic computer, and more like the human brain. As a functionally complex system, it heuristically defines its own functionality by changing connections so as to optimize how components interact. An effective city will be one with a system architecture that can respond to changing conditions. This analysis shifts the focus of understanding cities from their physical structure to the flow of information"

Posted by Ant at 04:09 PM | Comments (0) | TrackBack

An analysis of hated typefaces

Reviled fonts justified on Joe Clark's site. Thanks to Priya Prakash for rooting out this one...

Posted by Ant at 03:01 PM | Comments (0) | TrackBack

Identity Course

This paper on Identity and Deception in the Virtual Community by Judith S. Donath is a part of the course reading of an MIT course called Who we are and how we perceive ourselves and others... lots of great reading material here. Thanks to Dan Dixon for bringing this to my attention.

Posted by Ant at 01:56 PM | Comments (0) | TrackBack

Digital TV usability

Matt Jones found this usability rap-on-knuckles report about digital TV. Not surprisingly disparaging as DTV is a bitch to use and probably always will be until someone re-invents the square-peg-in-a-round-hole remote control unit.

Like the first computer interface was just a keyboard – a hangover from the analogue typewriter, the Digital TV remote is trying to take an interface for changing channels and volume into a controller for a basic computer... there's a comment on the linked page that says this better.

Posted by Ant at 01:35 PM | Comments (0) | TrackBack

October 07, 2003

A piano's lesson... interface confuses information.

Today I am the proud owner of a new Korg SP200 digital piano! I've been playing it a bit today and it's a real joy. Having grown up with a piano in the house as a kid, I have missed having one around to just plunk away at for relaxation.

Although the piano is not my first instrument, it's definately the one that I find the easiest to communicate with. It's to do with having all that visual feedback from the keys whereas with a saxophone or guitar, you just don't get that. You can see what you're pressing and then associate this action with the result it produces – a sound.

The interface with a piano has direct mapping too – there's no dual functioned keys. One key does pretty much one thing 'affords' pressing. So, as a teaching aid, it is far superior to most any other instrument because you can visually see the structure of chords and melodies.

The downside to this is making a connection between the visual patterns learned on the keyboard and those one must learn to read musical notation on paper. These are unfortunately not the same. When there are no learned visual patterns within the interface (such as with the saxophone, because you can't see the keys when you're playing), the patterns within music notation can be more easily 'learned by route' and translated into actions made by the fingers.

Music notation isn't just any old information though... or perhaps it is... It's a whole language in itself comprising letters, numbers, punctutation, sentences, phrases and more. So learning this language is less difficult when you don't have to cope with visual feedback too... or is it? Imagine being able to see how your mouth makes sentences when you're trying to learn a language. Is there an instance where visual feedback isn't necessarily a good thing? I don't know. I fear I've flown up my own backside here.

Posted by Ant at 11:37 PM | Comments (3) | TrackBack

October 02, 2003

New Title

At a meeting today where we saw some very cool Navahedron stuff by Nascent Form which I'll be writing more about at a later date (not so much the whizzy 3d navigation models, but more the information architecture behind them), Andy Tedd coined a term that I will now use in referring to what I do. You can call me a 'Senior Post-it Note Jockey'... lol...

Posted by Ant at 06:21 PM | Comments (0) | TrackBack

October 01, 2003

Trend toward Aesthetics? Nah...

Review on Boxes and Arrows about The Substance of Style: How the Rise of Aesthetic Value Is Remaking Commerce, Culture, and Consciousness

"Postrel points out that “'form follows emotion' has supplanted 'form follows function'.” How else do you explain the success of the iMac, Volkswagen Beetle, and the Michael Graves Toaster at Target?"

Sorry, this is just rubbish. Of course form still follows function. If the iMac, Volkswagen Beetle etc didn't function exceptionally well, they'd have been a flop.

The notion that people value aesthetics more now than they did then is a misnomer. People can afford aesthetics now, where before this was a luxury. As the population becomes more affluent and companies cotton on to the fact that people have always wanted aesthetics, goods become cheaper and more aesthetic.

People in poorer countries (or westerners earlier this century) couldn't care less about aesthetics. If something works, and they can afford it, then that's enough for them. If aesthetic goods were cheap enough, they'd have those instead, because the desire for beauty and individuality is something that runs deeper than trend. It roots in the way humans value themselves. This isn't transient, in my opinion.

Posted by Ant at 10:56 AM | Comments (0) | TrackBack