Posts Tagged “design”
Apr 14, 2019
On March 25th a Norwegian game jam for role-playing games started. It’s called R.I.S.K. (Rollespill.infos Intensive Spillskaper-Konkurranse) and it has been going on for several years now. The idea is that you have two weeks to design a role-playing game and make a decent PDF out of it. At the beginning of the jam they give you five words, and you have to use at least one of them in your game. This is to avoid that you start designing the game beforehand. I thought it could be a nice challenge, so I went for it.
The five words
The five words for this year’s jam were:
- Feiring (celebration)
- Hemmelighet (secret)
- Søke (to search)
- Vår (spring, as in the season, or our)
- Gift (poison, or married)
The one that caught my attention was the last (interpreted as “poison”), but I also used “secret”. The end result was “Mistankens gift” (“The poison of suspicion”), a game about life and forgiveness.
Concept of the game
The game has two main characters: a person who has been poisoned and is probably going to die, and the person who poisoned the first. It’s a game for two players, and each player will take the role of one of these two characters. The game is a succession of scenes, alternating between the poisoner and the victim. The victim’s scenes are meant to illustrate what made the victim’s life worth living, while the poisoner’s scenes are meant to illustrate negative sides of the victim the poisoner uses to justify what they did. The character sheet has questions that can be used as inspiration to come up with the scenes (things like “What did the victim always put before other people?” for the poisoner, and things like “Who would be heartbroken if you died?” for the victim).
I started writing notes with ideas for mechanics and game concept from the beginning of the jam, and soon I came up with some mechanics I liked (I think maybe Wednesday or Thursday?):
- Each player has two sets of dice. The first set is called scene dice, and the other opposition dice. Each set of dice has a 1d4, 1d6, 1d8, and 1d10.
- Before each scene, the player who is about to narrate it (the active player) will announce what the scene is going to be about. Then the active player chooses a dice from the scene dice, and the other player one from the opposition dice. If the active player rolls the same or higher, the scene will go as planned (highlighting the good sides of the victim, if the active player plays the victim, or highlighting the bad sides of the victim, otherwise) and the active player wins as many points as their own die showed. If the other player rolls higher, the scene will have to have some contrast or shadow of doubt, and the active player doesn’t earn any points.
- At the end of the game both players compare their points to a number between 10 and 15 called fate number, chosen by the poisoner player at the beginning and kept secret throughout the game. If the victim reached the number, the victim will survive. If the poisoner reached the number, the poisoner will be forgiven, either by themselves, or by the victim. Once the fate of both is known, both players agree on an epilogue.
The idea was to create some tension between the goals of the two players. Also, I really like the two layers of contrasts or conflicting points of view in the game:
- Both players are essentially presenting the same character (the victim) in very different lights.
- When they “lose” a scene, the players have to add a conflicting point of view of idea into the scene: poisoners will admit or realise that the victim wasn’t as evil or deserving of death than they wanted to believe, or victims will realise that their lives weren’t as good and positive as they wanted to believe.
The final PDF
To write the rules themselves I used LibreOffice, and to design the character sheet I used Inkscape. I put everything together using pdftk, and used illustrations from the British Library Flickr account, and I’m fairly happy with the final result.
I’m really happy that I participated, regardless of the outcome. I have played the game a couple of times (to playtest it) and I thought it was pretty enjoyable! The feel is fairly close to how I imagined it would be. I have several ideas about how it could be improved, but I’m not sure I’ll have the focus to do so. Time will tell. In any case, it’s perfectly playable as it is, and I thought it was fun both to design it and to play it.
If you want to try it out, you can download the game from its homepage. You need a second player, a printout of the character sheet (also available as the last page in the rules themselves), at least one die of each type (4-, 6-, 8-, and 10-sided dice), and something to write with. It takes about one hour to play so it’s not a big time investment.
Edit: If you’re interested in seeing the initial design notes, including all the ideas that didn’t make it into the game, and the false starts, you can have a look at them: page 1, page 2, page 3, page 4.
Feb 2, 2013
Laying out the comic
Once the script is ready, you sketch the comic storyboard to answers these questions:
Composition of each panel (where characters go). See example on p.108. Tips: rule of thirds, writing speech bubbles first to use space better, avoid intersecting lines in foreground and background.
Perspective (how the audience will look at the characters). Use and be aware of perspective and distance (where the camera is). For inspiration, have a look at Wally Wood’s “22 panels that always work”.
Flow & progression (change of locations, how time passes, …). What happens between panels should be obvious. Take care of small details like which hand is used, or the side of something.
Drawing and refining
Resources to make higher-quality art, faster:
Reference materials: tracing over stuff is easy, quick and gives good results (eg. photographs, incl. made by yourself for the purpose, or avatar generators like IMVU or XBox).
Templates: a couple available on the net, but tend to be limiting. Create your own templates?
Comic creation software: several, seem too complex and/or expensive.
Possible uses of comics:
Requirements/vision: documents don’t get read, and if they do, they’re ambiguous. Comics are easy to read and explaining requirements through real use-cases often works better.
Good start for projects/companies: comics help you validate your ideas before you build anything, or decide exactly what to build. In these cases, make the person read the comic on her own, then explain with her own words as she reads again. That way, misunderstandings are easier to spot. Also, make people say how it relates to them: if they or someone they know would use it.
Marketing materials. Explaining your product, or why it’s special, through comics.
Certain kinds of documentation.
It’s generally easier to get people to read comics than to read text descriptions of the same content.
Breaking Down the Barriers
When convincing bosses to approve the use of comics, there’s usually less resistance than what people think. That said, understand who you’re convincing and what arguments to use (eg. some designers think that comics take relatively little time compared to alternatives, or the evidence suggesting that words + pictures help in understanding and memory). Fidelity and polish in comics (and any other medium) needs to be higher for certain audiences, eg. bosses or corporate clients.
Useful templates and references
The appendix has ideas about how to show someone in front of a computer, interesting panels, gesture dictionary and a facial expression dictionary:
Jan 31, 2013
Oh, boy. It’s been a while, hasn’t it? This is the first post of the year, and it will be about the first book I’ve finished, “See What I Mean” by Kevin Cheng (which, by the way, I got from O’Reilly’s Blogger Review Program). It’s a book about using comics “for work”, to communicate ideas like product concepts, user stories, and such, more effectively.
This post will cover about half the book, from chapters 2 to 5. These notes are much more useful if you have the book to refer to the pictures, but hey, this is mostly for me ;-)
Properties of comics
Basic vocabulary for the anatomy of comics:
Properties of comics:
Communication: comics don’t need words, or can express a lot without them (p. 23). They’re universal!
Imagination: characters with few features make more readers relate. This can be applied to UI mockups/sketches, too: people focus less on design if it’s abstract (p. 25,26).
Expression: give interpretation to words (“I’m sorry”/”Thank you” examples with different facial expressions on p.27). When combining text and pictures, the sum is bigger than the parts.
Time: comics can express time passing by using empty or repeated panels. Also, via words in “narration” and reference objects (like burning candles, clocks, or day/night).
Drawing faces is easy! Eyebrows and mouth go a long way to express mood. Body language helps quite a bit, too, and it’s easy to represent. See examples of combinations of eyebrows and mouths on p.47, 48. In faces, eyes go in the middle, and dividing the bottom half in three gives bottom of nose and mouth. Also see http://www.howtodrawit.com for tips on how to draw different things.
Approx. proportions for a person are two heads for torso, 1 for hips/groin, and 3 for the legs. Body language basic guidelines: leaning forward shows interest, concentration or anger (depends on arm position and context; curling the spine works, too); arm position can tell a lot (lifting one or both, on chin, in front of body); head positions don’t change much, but facial expressions or where the person is looking, does. When drawing body language, try to imagine the situation and exaggerate it. It often helps to start with a stick figure, then add detail.
Steps to create a comic
There’s no single correct way to create a comic. One possible approach:
What’s your comic about? Why you’re using comics, what to include, who’s the product and comic for. This chapter is about this step.
Writing the story: create scripts in words, an outline, define characters, setting and dialogue.
Laying out the comic: plan each panel, what to show and how much of it.
Drawing/refining the comic.
What’s your comic about?
Don’t approach the question broadly and vaguely, break it down! Define goals (what to accomplish), length (3-8 panels encouraged; should fit on site homepage, a postcard or e-mail; if longer, consider physical prints), audience (expertise level, context), and representative use case (help your readers understand why they should care).
Writing the story
When writing a script, you can use a similar format as that of film scripts. Each panel’s needs four primary elements:
Setting (defined up front, usually in bold). It can be time of day, location, or maybe what happens in the background. It depends heavily on the audience. The first panel can help with the setting (“establishing shot”). There are different graphical ways to convey a setting: the description of it describes a concrete way (eg. exterior of coffee shop vs. interior of coffee shop vs. close-up of coffee cup being served).
Characters (all caps, bold). There are several types: target audience, people who interfact with them, and objects/locations that play a significant role (eg. the solution). Target audience is typically based on personas, go make them if you don’t have them already.
Dialogue (regular font). It’s defined by more than the text itself: fonts, sizes, colours, bubble shapes or the split into different bubbles are very important, too! The text can be hard to get right: make it fit the character, keep it realistic (avoid marketing jargon and overly enthusiastic conversation). Captions can communicate time, setting, action, and even dialogue, but don’t add unnecessary information in them, and always try to speak from the character’s voice.
Actions (usually italics). It’s what characters do, depicted in the panel art.
How to tell a story: remove all unnecessary. You can combine several points in a single panel. Show, don’t tell. See examples on p.98-100.
And that’s it for today. In a few days I’ll publish the rest of the summary.
Mar 8, 2012
This is my summary of the book “Living with Complexity”, by Donald A. Norman (of “The Design of Everyday Things” fame, among others). It’s a book about how it’s wrong to consider complexity (in design) a bad thing. I have skipped a fair deal of the text in the summary, mostly because it wasn’t applicable to my job. I have also reorganised the content a lot.
Complexity in itself is neither good nor bad, it’s confusion that is bad. Good design can help taming complexity, not by making things less complex, but by managing the complexity. There are two keys to cope with complexity: design that show its underlying logic to make it understandable, and our own skills and understanding of that logic. People need to take the time to learn, understand, and practice, because systems that deal with complex activities will not be immediately understandable, no matter how well they’re designed.
The misguided cry for simplicity
The argument between simplicity and features is misguided: people want more capabilities and more ease of use, but not necessarily more features or more simplicity. What people want is understandable devices. It’s not even a trade-off between simplicity and complexity because (a) simplicity is not the goal, and (b) you don’t have to give up something in order to have more simplicity.
We seek rich and satisfying lives, which goes along with complexity. Too simple and it’s dull; too complex and it’s confusing. This happens in every subject (also music, movies, etc). The problem is when complexity is arbitrary and unnecessary.
What makes something simple or complex is the conceptual model of the person using it: many activities we think of “intuitive” now, like swim or ride a bike, have taken us years to learn and master. We can often use something by following instructions, without having a good conceptual model. But then we run into problems, and we complain that it’s too complicated. Comparisons with tools like hammers are wrong, because (1) even if the tool is simple, mastering its usage actually takes a long time; and (2) users of those tools typically need many of them, and each one has to be mastered separately.
On anti-social machines
Machines are often anti-social when things go wrong: they become unresponsive and unhelpful, like bureaucracies. The problem is that the designer typically focuses on correct behaviour (ie. not a lot of work on error conditions). This is worse when systems are designed by engineers who view things from their logical point of view, feel people “get in the way” (the “foolproof” systems syndrome).
We try to add intelligence to machines, but what they need (and this is seldom considered) is communication skills, etiquette and communication. We often need to change our goals in the middle of an operation, or want to substitute or skip some steps, or do them in a different order, or are interrupted and have to finish a task at a later point. Most systems don’t allow this. Isolated, context-free intelligent tools can’t be sociable.
System thinking (considering the entire process as a human-centred design) is the secret to success in services. This is part of what has made Apple so successful: (1) design cohesive systems, not isolated products; (2) recognising that a system is only as good as the weakest link, and (3) design for the total experience.
Desire lines (like messy trails besides the designed paths in the real world) can often teach us something about what people want and how the design might have gone wrong. Neglect of usage patterns can turn simple, attractive items into complicated, ugly ones, and also turn simple components into a complicated combination when they are put together. Everyday life is often complex not because of a single complex activity, but because of many simple activities with different requirements or idiosyncrasies.
Waiting lines have been studied from the efficiency point of view. But what about the experience? Principles to improve the latter:
Provide a conceptual model (perhaps the most important principle): uncertainty is an important cause of emotional irritation; people need assurance when they have problems.
Make the wait seem appropriate: people should know why they wait, and agree that it’s reasonable.
Meet of exceed expectations: always overestimate waiting time.
Keep people occupied: it’s psychological time, not physical, that is important. Give people things to do, keep lines moving and make them appear short.
Be fair: emotion is heavily influenced by perceived causal agents.
End strong, start strong: in order of importance, the end, start, and middle are the most important to take care of.
The memory of the whole event is more important than the details of what happened. When there are positive and negative components, it’s best to: finish strong, segment the pleasure but combine the pain, and getting bad experiences out of the way early.
Principles to manage complexity
Note that this list is heavily edited compared to the book.
Make things understandable. Good conceptual models have to be communicated effectively. Jurg Nievergelt and J. Weydert argued for the importance of three knowledge states: sites, modes and trails, which can be translated into three needs, namely knowledge of the past (knowing how we got into the present state; many systems erase the past so we may not know how we got there), present (knowing the current state, how are we regarding starting point and goals, and what actions are possible now) and future (knowing what to expect).
Avoid error messages. They indicate the system is confused, not the user. Don’t scold her. Good design means never have to tell the user “that was wrong”.
Structure. Divide the task into manageable modules that are easy to learn, or find a different way to frame the problem so it’s less complicated.
Automation. Many tasks can be simplified by automating them, but this only helps if it’s reliable: when there are errors, it can be more complex to switch back and forth between automated and manual than to not have any automation at all.
Nudges and defaults. Sometimes forcing functions (constraints that prevent unwanted behaviour) are too strong, all is needed is a gentle nudge. Defaults are an effective way to simplify the interaction with the world, and a strong tool to drive people’s behaviour.
Learning aids. Instruction manuals are rarely read. When people use a new service or system, they have a goal, they’re not going to read the instructions first. Most people want “just in time” learning and learn better when they need to. The best explanations are in context and show how the task is done (short video demonstrations work well).
And that’s it. Hope you enjoyed it.
Nov 10, 2011
These are my notes about “Envisioning information” by Edward R. Tufte. It’s not a normal summary because most of the content needs the graphics, plots and figures being discussed. The following notes cover the whole book (six chapters).
EDIT: Manuela wrote another, easier to read summary.
The methods in this book work to increase the number of dimensions that can be represented on plane surfaces and the data density. Nearly every escape from flatland demands an extensive compromise, trading off one virtue against another. Even our language often lacks capacity to communicate a sense of dimensional complexity. Some design strategies are found again and again (examples of over 380 years of sunspot data analysis). These design strategies are surprisingly widespread, albeit little appreciated, and occur independently of the content of the data.
Massive Java railroad line example on p. 24-25. The train diagonals cleverly multiple-function, recording six variables at once (p. 26). Example of criminal activity for a trial on p. 30-31. The chart invites reading both horizontally and vertically. The eyes detect curious patterns, which make these displays persuasive and memorable. Visual displays of information encourage a diversity of individual viewer styles and rates of editing, personalising, reasoning and understanding. Unlike speech, visual displays are simultaneously a wideband and a perceiver-controllable channel.
We envision information to reason about, communicate, document and preserve that knowledge. Chartjunk on p.34: data-thin, uncontextual graphs. Its promoters imagine numbers to be dull and tedious, requiring ornament. If numbers are boring, you got the wrong numbers. The audience might be busy or eager to get on with it, but not stupid. Chartjunk looks more like a poster, meant to be looked at from a distance (thin data density).
Detail cumulates in coherent structures. Simplicity of reading derives from the context of detailed and complex information, properly arranged. To clarify, add detail. Stem-and-leaf plots of statistical analysis also rely on micro/macro design (examples on p. 46-47).
We thrive in information-thick worlds because of our marvellous and everyday capacities to select, edit, single out, structure, highlight, group, … Visual displays rich with data are not only an appropriate and proper complement to human capabilities, but also such designs are frequently optimal. If the visual task is contrast, comparison and choice, then the more relevant information within eyespan, the better. Low-density requires visual memory, a weak skill. High density also allows viewers to select, narrate, recast and personalise data for their own uses.
What about information overload? The question misses the point. Clutter and confusion are failures of design, not attributes of information. Interesting quote on typography on p. 51. The deepest reason for displays that portray complexity and intricacy is that the worlds we seek to understand are complex and intricate.
Layering and separation
This technique is one the most powerful devices for reducing noise and enriching the content of displays. The various elements interact, creating non-information patterns and texture simply through their combined presence (1 + 1 = 3 or more). Colour effortlessly differentiates between annotation and annotated (example on p. 54). What matters is the proper relationship among information layers (example of old + improved design on p. 54-55). For tables, try to do without rules altogether, only use when absolutely necessary. Example of map (good and bad) on p. 58. Example of (non-)dull background on p. 59. Notes on how 1 + 1 = 3 can also be applied to noise on p. 61-62. Example of use of colours (another bad + good design) on p. 63.
Information consists of differences that make a difference. A fruitful method for the enforcement of such differences is using layering and separation.
Quantitative reasoning is based on “compared to what?”. Small multiples answer by visually enforcing comparisons of changes, of the differences among objects, and the scope of alternatives. Information slices are positioned within the eyespan, so that viewers make comparisons at a glance. Example of drawing a Kana character on p. 69. Simultaneous two-dimensional indexing of the multiplied image, flatland within flatland, significantly deepens displays with little added complication in reading.
Colour and information
Example of Swiss mountain map on p. 80. Fundamental uses of colour in information design: label (colour as noun), measure (as quantity), represent or imitate reality (representation), enliven or decorate (beauty). Principles to minimise colour damage: (1) pure, bright colours have loud, unbearable effects when they stand unrelieved over large areas adjacent to each other, but can work very well when used sparingly on or between dull background tones; (2) placing of light, bright colours mixed with white next to each other usually produces unpleasant results, esp. if the colours are used for large areas; (3) large area background or base-colours should do their work most quietly, allowing the smaller, bright areas to stand out most vividly (strongly muted colours, mixed with grey, provide the best background for the coloured theme).
What palette of colours should we choose to represent and illuminate information? Use colours in nature (familiar and coherent, possessing a widely accepted harmony to the human eye), esp. those on the lighter side such as blues, yellows, and greys of sky and shadow. Great examples on p. 90.
In the ocean map, quantities are shown by a value scale, progressing from light to dark blue. Colour rainbows confuse viewers to mumbling colour names and the numbers they represent (“To see is to forget the name of the thing one sees”). Colours are sensitive to context. In the ocean map, contours (which are very helpful) are labelled with depth measurements. Edge lines allow very fine value distinctions, increasing scale precision. Example of bad map/good colour on maps on p. 94-95.
Narratives of space and time
Example of bad/good train schedule on p. 104-105. Space-time grids have a natural universality, with nearly boundless subtleties and extensions. Great, assorted examples on p. 110-111. Example of “tale of two cities” on p. 112-113.
I’m aware that this summary is not very useful if you can’t see the different diagrams being examined, but it’s partly for myself :-) Anyway, if you like the ideas in the book, go buy it, it’s a great book in a big format, with really nice paper and full of very interesting examples of both good and bad information design.
Aug 19, 2008
The other day I was talking about upgrading Typo. The update itself went well, true, and the site was up and running without too much downtime, but then I started using it again… and I have noticed two things so far (both about writing posts) that I really dislike:
First, the good old editor is not there anymore: the Typo editor used to be really good, because on the left hand side you had a very reliable and easy to use textarea with Wiki syntax (you can choose which exact syntax you want), and on the right hand side you had a “live preview” of your post, automatically updated with Ajax, that showed you how the post was going to look like. Well, that’s gone. Now there are two options: some retarded WYSIWYG box, that I tried to use and failed, and some good old textarea… without the damn live preview. That sucks big time, because there is no other preview (that I have seen: please enlighten me if there is indeed one), so I just blindly write things in a Wiki format, and hope that it’s going to look OK when I press “Publish”.
Second, I was playing with the Wiki format for the articles, and I changed it to “Markdown” (I always mix “Textile” with “Markdown”, and never remember which is which; the one I prefer is Textile). After I hit “Save”, not only the next article was parsed in Markdown format by default, but every single blog post. It’s like, you select the parser the system is going to use to interpret your whole blog. How retarded is that? Once you have written posts, it doesn’t make sense to change their syntax (unless you do it manually editing the post itself). Clearly the format is a property of each blog post, not of the whole blog installation.
Not everything is bad though: it seems that now you finally have a “Draft” concept, so I can start writing a blog post and just save as a draft, instead of unticking the “Online” property and saving as a normal post. Also, the drafts are saved automatically, so I don’t have to remember to hit “Save” from time to time just in case the browser crashes or I hit something stupid and erase the contents of the post. Yay for that.