Though an initial idea is:

I’m going on the idea of an embossed notebook, aiming at a more personal feel – which is why it’s almost invisible. In case it’s unreadable:

VISIONS

collab + create

Development is needed.

I read about IDEO’s approach to Focus Groups, as well Mike Kuniavsky’s advice in Observing the User Exerience: A Practitioner’s Guide to User Research, I thought about bringing context to the group by “setting homework”, and “engaging participants” with activities. This meant planning the two following activities:

Activity 1: Sharing Notebooks

I will ask all participants to bring a regularly used notebook of their ideas. Each participant will explain a bit about their thought process while displaying their book, whilst I quiz them more about specific details as they arise. Questions could follow these guidelines, with deeper investigation as appropriate:

1. How often do you use the notebook?
2. When was the last time you put something in it? Where were you?
3. Have any of these ideas been developed further?
4. Have you shown or talked about that idea with anyone?
5. Do you ever look back at your previous ideas?
6. How do you know which ideas to develop further, or which to drop?

Activity 2: Rapid Concept Development

…or “Mind Mapping”

The group will be split into smaller teams of around 2 to 3 people; each participant is to be given a blank piece of paper.

• Everyone will be asked to write, draw or visualise a concept for an possible project in the centre of the page – a box will be printed to confine the initial input.
• Everyone is asked not to talk, but to pass their concept to the person on their left.
• Each person is then to add at least one thing to the page, in the style of a Mind Map. All are asked to put their initials next to any contributions.
• The page is passed to the next person, and the process repeated – participants are able to add or comment on other people’s contributions.
• This cycle continues until the page is returned to it’s owner, where they can ask the contributors directly about any feedback given.

There are 2 objectives to this activity:

1. Observe and note the concept sharing process in miniature, for a better understanding of the structure and reactions.
2. Observe the media used to convey ideas – pictures, words, references etc.

After an oddly difficult installation, re-installation, and re-re-installation, I got it working, and began to experiment with the user settings. I think I’m going to need to rethink the activity flow, as WPMU only seems to allow users to have one blog of their own, and only if they choose one at registration.

The original plan would be for users to register, then add as many separate projects (blogs) as they like, and add other users to that project – potentially, a MU blog within a MU blog. I’m sure there are strategies around this, I just haven’t found them yet.

I’ve also been spending some time trying to recruit users, as Bower Ashton hasn’t replied, but a new set of artists is on the horizon.

Where he spoke about “re-framing” the web, by not only linking documents that have relevance to one another (which was the initial idea for the web), but by extracting the subjects and topics from these documents (e.g. specific people, events, places, etc.) as data, and linking them together. Linked Data.

Berners-Lee suggests that there are 3 rules of Linked Data, which are:

1. Subjects of data should have their own HTTP address (e.g. places, people, objects, events etc.)
2. Fetching this page will produce standardised data about the subject
3. Relationships will emerge between this and other data, enabling users to browse (e.g. a person was born in Bristol, which is in the South West of England, which is part of the United Kingdom, etc.)

In this way, people would be able to browse and search the web in a totally different way – because all the data surrounding a subject (or document) would be in a standardised format, and could be cross-referenced at a much deeper level. It would change the web from a human-readable resource repository, into a database of standardised, organised data, which machines would be able to process and connect.

But I haven’t decided which ones to review yet. I like Eye though.

The main things I’ll be looking at though are:

• Visibility of Current Issue & Topics
• Ability to “Preview” the Magazine (e.g. E-Publishing like Issuu)
• Subscription Process
• Archive of Back Issues
• Newsletter Signup Process

More research is needed.

When I started reading, I got the overwhelming sense that I was reading a self-help book, not advice on design pitches, like I had expected (LESSON: always read the blurb before buying a book). However, once the initial “you can be successful too” spiel was over, the book actually has some useful advice for anyone wanting to pitch, present or generally get their points across. Such as:

• Write the presentation before you touch PowerPoint, so that the content of the pitch doesn’t get side-tracked by aesthetics and animations before it’s fully formed.
• Think of the pitch like a story, with beginning middle and end – begin with a proposition, develop the points of your argument, and summarise at the end.
  This point also has enforces the “say it three times” rule of Marketing. By introducing the idea, then exploring the points in detail, and finally going over the idea along with your arguments, the idea should be embedded in the audiences head by the end.
• Never summarise at the beginning, just the end. If you lead the audience through the story of the pitch, they will understand the questions and the background of the process, not just the answer.
• Don’t write a script, just write the themes of each slide, but not the words. Being able to talk fluidly, without needing to refer to notes will help the flow of the presentation, as well as giving the impression that you are in command of the content, not the other way round. It also makes it easier to recover the flow if there are any interuptions.
• Have one focal slide, that the rest of the pitch pivots around, to make it as clear as possible to the audience what your proposal is getting at.

The book also develops ideas on how to appear more confident, and therefore more likely to make the audience respect what you have to say:

• Keep the pitch simple and clear. A clear pitch will be easier for the audience to follow, and will make you seem more in control of what you are proposing.
• Don’t fill your pitch with statistics and numbers (or at least, don’t dwell on these figures during the pitch) – have stats ready for any questions, but during the pitch, you should try to convey the emotion behind the proposal.
• Rehearse to a mock-audience to perfect the content, rehearse alone to perfect the pitch. Rehearsing is obviously key to feeling confident in the material, but having to try and deliver the full pitch to peers can be embaressing. If you focus on perfecting the clarity of your points with a mock-audience (who can give feedback), you can centre on the tone, emotion and personality of the pitch in a mirror, where no one can hear your shameful jokes.

As well as presentations, the book has useful tips about writing CVs that stand-out for the right reasons, and about the psychology of the pitcher-audience relationship, which can be useful to know, rather than just learning a set of “rules” as a mantra.

Unfortunately, there is an underlying tone of chauvinism in parts of the book, which makes reading it a little off-putting – but generally, the advice in the book is clear and helpful.

Work always looks less shiny when you look back, because now you’re looking back, you know a lot more about the topic than you did. Maybe it’s just pure self-hate?

On the plus side, I now have a better idea of how to tackle user-testing, and I also read Chapter 1 of “Designing Interfaces” by J. Tidwell, which has some interesting points about…well, designing interfaces. As with most practical advice on design / project management / etc., a lot of it is common-sense, but it isn’t obvious until someone has pointed it out, but now that they have, the world seems a little less depressing.

Checking accessibility of a website is made a little easier by the A Checker (http://achecker.ca/checker/index.php). In a familiar “validation” layout, it is simple to enter and quickly check a websites comformance to common accessibility rules.

The output not only provides any offending content, but also a “Repair” statement that explains, in plain English, how the problem can be fixed:

Repair: Remove the font element from the document.

As with other validation tools, the word of the A Checker should not be taken as Gospel, because not all computed errors may be a problem in real-world use – human judgement is needed to make sure that regulations do not sour the human experience of a website, whilst maintaining a standard of accessibility for all users.

The one drawback to this is the ambiguity of some of the warnings:

Line 1, Column 120: script may use color alone.

Without any further explanation of the possible problem, or any advice on how to fix it, and with 87 “potential problems” listed for Google, it is understandable that a lot of web developers find the task of accessibility daunting.

As with CSS, it is not possible to provide the same experience for everyone who will use a site, but with careful consideration of known problems, paired with validation tools, the process can be somewhat simplified.

Browser Shots (http://browsershots.org/) allows you to see what a website looks like on a variety of browsers, operating systems, resolutions and with different technologies disabled or enabled.

Once you have submitted a URL, the system takes screenshots of the site, with the selected filters (e.g. browser). The results are obviously static images, but it is an invaluable tool for developers who have limited access to a variety of machines. As a Mac user, this tool has made the process of testing designs (and correcting) for compatibility and accessibility much less painful.