tag:blogger.com,1999:blog-289199812024-02-08T14:31:01.413+01:00on interaction architectureAnonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.comBlogger97125tag:blogger.com,1999:blog-28919981.post-68368886359154542522017-06-24T18:30:00.000+02:002017-06-24T18:30:48.580+02:00the world needs more fonts, honestly<p class="hang"><span id="teaser">‘Can you name one problem which type
design (not engineering) solved and which is not predominantly
aesthetic?’ Now that caught my attention
<a href="https://twitter.com/MrBrezina/status/876500471942443008">on twitter</a>.</span> It appeared
in a thread that started off with some
<a href="https://twitter.com/ninastoessinger/status/876156829826510852">saucy quotes</a>:
‘the problems have already been solved’ and ‘the function of
new typefaces is largely aesthetic.’</p>
<p>It piqued my interest because I have worked on the interaction design of a
couple of font design applications. Besides that I have spent a lot of time
investigating the general nature of design.</p>
<h3>making a splash</h3>
<p>So I jumped in and joined the twitter discussion. After a false start (oh,
the joys of social media) the heart of the matter
<a href="https://twitter.com/MrBrezina/status/876691100572016644">came to light</a>:
‘It is about problems that typefaces solve, not about the problems of
typeface design practice, i.e. the categories of reasons why to draw.’
So I addressed it there, have been thinking about it quite a bit more since
then, and now I am going to address it better.</p>
<p>Let’s start with a smooth aikido move to get this discussion positioned
where it belongs. When a font is to be used by many (i.e. more than 100)
people, then it is a product. The type designer is the product designer; the
design process is the act of product realisation. The process starts with a
product definition; methodical research and design follows. Eventually a set
of design drawings is created, to be engineered into shippable fonts.</p>
<p>This insight rebases the discussion. <strong>It is a product issue, not a
design issue.</strong> Asking what problems type design can solve today, is
asking: are there any product definitions left that aim to bring useful,
valuable font solutions to users?</p>
<p>Well, allow me to make some suggestions.</p>
<h3>think big, really big</h3>
<p>If you write using Latin script, then it seems that you have 100.000 fonts
to choose from. If you write in another script, you are suddenly scraping the
barrel; 100 usable fonts is then super luxurious. Does this impact just some
tiny minorities? Well, here is a handy list:
<a href="https://en.wikipedia.org/wiki/List_of_writing_systems#List_of_writing_scripts_by_adoption">writing scripts sorted by usage</a>.
If I skip Latin and add up the populations that actively use the next ten
scripts, then I end up with <strong>3.41 billion people</strong>.</p>
<p>The ten scripts are: Chinese, Arabic, Devanagari, Bengali‐Assamese,
Cyrillic, Kana, Javanese, Hangul, Telugu and Tamil. Right after these on the
list there is a group of six modestly used scripts (Gujarati, Kannada,
Burmese, Malayalam, Thai and Sundanese) that nonetheless serve another
205 million people.</p>
<p>Here is my suggestion: Want to do something useful? Pick a popular Latin
font (family), say from the top‐1000 in use, and pick one of the
big‑10/modest‑6 scripts listed above. Your product definition is
to design a font in that script that <em>goes together seamlessly</em> with
the Latin font. That does not mean that your new font has to play second
fiddle to the Latin one; just that they get along famously.</p>
<p>I can tell you from experience that it is <em>very</em> rewarding to design
something this relevant; with the knowledge that tens, if not hundreds, of
million of people are waiting out there for the results. Of the
3.615 billion people mentioned above, a good chunk owns a smartphone or
will own one soon—you cannot stop commodity Android. It’s their
access to the internet. They inform and express themselves using text.
They need fonts.</p>
<h4>fit for purpose</h4>
<p>Read a book on typography and one discovers that non‐philistine
typesetting starts with using proper numbers (oldstyle vs. lining, &c.), small
caps, and so on. Now check 10 random fonts on the device you use to read
this post. Do they contain a full set of numbers and small caps? It is going
to be hit and miss. Personally, I am <em>still</em> waiting for oldstyle
numbers for my favourite Swiss sans.</p>
<p>While typesetting got more efficient (hot lead, to photo, to digital),
typography support got thrown overboard. Today, typography is banned to the
graveyard called OpenType features. Yes I know, <acronym>OT</acronym> features
UI is a world of hurt, but someday someone is going to do something about it
(if that is you, ping me). Meanwhile, it is 2017 and fonts that just support
the skimpiest of Latin glyph set feel very ‘ms‑dos’ to me;
primitive, with a touch of nostalgia, but surely past due date.</p>
<p>So my second suggestion is to start doubling down on OpenType features. Go
through the top‐1000 list of fonts and start extending them to make them
useful, and valuable, for typographers. I realise there are some barriers
of entry, like intellectual property and access to source files (so that they
can be extended). Maybe you can pitch the company that owns them and get the
gig. A straightforward case is open source fonts, you can get started
right now.</p>
<h4>fit for authors</h4>
<p>Bold and italic are not just a good idea, they are (by default) the way to
express certain conventions in text, e.g. emphasis, or denote publication
titles. The defaults of html & css are an example of how enshrined this is. A
week ago I was trying to select some typefaces for a new website, and it was
an uphill struggle, littered with missing italic and/or bold font variants.</p>
<p>My third suggestion: there are plenty of holes in the top‐1000 fonts
where it comes to bold and italics. Your product definition is to fill some of
these, where you think it matters most. Designing a bold for someone
else’s regular can be a drag. But italics can be worthwhile design work,
because they start with a clean sheet and a different skeleton than the
regulars. I suspect the amount of true‐design work involved is the
reason italics got skipped in the first place.</p>
<p>Speaking of, here is a bonus product definition: real italics to be used
seamlessly with that famous Swiss sans—to replace them obliques. Again a
clean‐sheet project which solves a typographer’s problem. And an
ambitious, high‐profile one too. You can call it Helvetalics, if
you like.</p>
<h4>fit for a new medium</h4>
<p>Last year I was involved in an internet‐of‐things project.
After a methodical start, it became immediately clear that for our combination
of display (size, resolution), use (viewing distance, information density) and
goals (not end up being cheap junk slapped together by engineers) we needed a
font to make it work. Yes work; life or death.</p>
<p>New media to display text, with new properties—and new contexts for
old ones—pop up regularly. These events naturally trigger product
definitions for fonts to make new media work.</p>
<h3>aesthetics, schm’sthetics</h3>
<p>In this blog post I have not gone into aesthetics, because I didn’t
need to. All I have done is look beyond the glyph shapes and spot
ocean‐sized holes in the font product landscape. Just following up on my
first suggestion will keep the global type designing community busy for
decades with work that is 100% non‐frivolous. Suddenly today’s
‘glut’ of type designers looks like it could use some serious
reinforcement troops.</p>
<p>A business coach once told me: ‘this design work you do is political,
isn’t it?’ She meant that my design clearly impacts society and
that my design decision make the world better, or worse. That starts with the
decision ‘what project do I work on?’</p>
<blockquote>If you get to decide the product definitions at your font shack,
then your work is political.</blockquote>
<ul>
<li>Your choice of scripts is political; how many of 3.615+ billion
people are you gonna throw under the bus?</li>
<li>Your choice of OT features is political; a font for typographers, or only
for simple business administration?</li>
<li>Your choice of including a bold and italic is political; is your font
going to be a drop‐in solution for those who just want to
communicate?</li>
<li>Your choice of targeting new display media is political; are you going to
leave their new users out in the cold?</li>
</ul>
<p>If you scour the font landscape, looking for pockets of
<em>user‐felt</em> hurt (‘what, <acronym>XYZ</acronym> simply
doesn’t exist?’) and then do something about it by creating, or
updating, a font product, then your work is political, useful and valuable.
And I salute you.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com5tag:blogger.com,1999:blog-28919981.post-82171352441209909682016-09-14T10:25:00.000+02:002016-09-14T10:25:13.568+02:00bicycle, node, network, design<p><span id="teaser">This Monday <a href="http://igniteberlin.com">ignite berlin</a>
took place and I did a fun, five minute, pecha kucha talk that also contained some
systems analysis and a design insight.</span> For a full transcript, read on.</p>
<h3>ring ring</h3>
<p>There are two things that you need to know about me. The first is that I am
dutch and the second is that I am becoming a sentimental old fool. I combine
the two when I do cycling holidays in Holland:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/ontour.jpg"
alt="cycling in the dutch fields" width="380" height="214"/>
<cite>my partner Carmen leads the way</cite>
<p>For this we use the <i>fietsroutenetwerk</i>, the <strong>bicycle route
network</strong> of the Netherlands. This was designed for recreational
cycling in the countryside. It was rolled out between 2003 and 2012. The
network is point‐to‑point:</p>
<img src="http://mmiworks.net/pics/blog16/point2point.png"
alt="two points connected by a line, arrows pointing both ways"
width="380" height="187"/>
<p>Between two neighbouring nodes there is complete signage—with no
gaps—to get you from one to the other. And this in both directions.
Here are some of these signs:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/signage.jpg"
alt="several roadside routing signposts" width="380" height="214"/>
<cite>sources: <a href="https://fietsenopdefiets.wordpress.com/fietsen-langs-knooppunten/">fietsen op de fiets</a>,
<a href="http://www.hetgroenewoud.com/applications/hetgroenewoud/files/afbeeldingen/Website_apr_2014/Foto_pagina_-_Bewegen_-_Fietsen.jpg">het groene woud</a>,
<a href="http://forum.gps.nl/viewtopic.php?t=2469&start=90">gps.nl</a></cite>
<p>The implicit promise is that these are nice routes. That means: away from
cars as much as possible. And scenic—through fields, heath and forrest.</p>
<p>Using the nodes, local networks have been designed and built:</p>
<img src="http://mmiworks.net/pics/blog16/localnet.jpg"
alt="a network of nodes on a local map" width="380" height="214"/>
<p>These networks are <strong>purely infrastructural</strong>; there is no
preconception of what is ‘proper’ or ‘typical’
usage. They accommodate routes of any shape and any length.</p>
<p>At every node, one finds a local map, with the network:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/nodemap.jpg"
alt="on-location display of the local map" width="380" height="214"/>
<cite>source: <a href="https://commons.wikimedia.org/wiki/File:Maasbracht_(Maasgouw)_knooppunt_10_fietsroutenetwerk.JPG">wikimedia commons</a></cite>
<p>It can be used for planning, reference and simply reassurance. Besides
that, there are old‑fashioned maps and plenty of apps and websites
for planning and sharing of routes.</p>
<p>The local networks were knitted together to form a national network:</p>
<img src="http://mmiworks.net/pics/blog16/nationalnet.jpg"
alt="a dense network covers the whole country" width="380" height="214"/>
<p>Looking at this map I see interesting differences in patterns and
densities. I don’t think this only reflects the geography, but also
the character of the locals; what they consider proper cycling infrastructure
and scenic routes.</p>
<p>The network was not always nation-wide. It was rolled out over a period of
nine years, one local network at the time. I still remember crossing
a province border and (screech!) there was no more network. It was back to
old‑fashioned map reading and finding the third street on the left.</p>
<h4>not invented here</h4>
<p>I was shocked to find out that the Dutch did not invent this network
system. We have to go back to the 1980s, north‐east Belgium: all the
coal mines are closing. Mining engineer Hugo Bollen proposes to create a
recreational cycling network, in order to initiate economic regeneration of
the region. Here’s Hugo:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/Hugo.jpg"
alt="Hugo Bollen rides a bike in nature" width="380" height="214"/>
<cite>source: <a href="http://www.toerismelimburg.be/nl/mijnverhaal/as">toerisme limburg</a></cite>
<p>He designed the network rules explained in this blog post. The Belgians
actually had to build(!) all of the cycling infrastructure, so it took
them to 1995 to open the first local network. It now brings in 16.5 million Euro
a year to the region.</p>
<h3>how many?</h3>
<p>I got curious about the total number of network nodes in Holland.
I could not find this number on the internet. The net is really quite
short on stats and data of the cycling network. So I needed to find out by
myself. What I did was take one of my maps—</p>
<img src="http://mmiworks.net/pics/blog16/mymap.jpg"
alt="a traditional cycling map that covers a part of holland"
width="380" height="214"/>
<p>And I counted all the nodes—there were 309. I multiplied this
with the number of maps that cover all of Holland. Then I took 75% of that
number to deal with map overlaps and my own over‐enthusiasm. The result:
I estimate that the dutch network consists of 9270 nodes.</p>
<h4>in awe</h4>
<p>The reason I got curious about that number is that every time I use the
network, I am impressed by a real‐genius design decision <em>(and I
don’t get to say that very often)</em>. It makes all the difference, when
using the network in anger.</p>
<p>All these nearly‐ten thousand nodes are identified by a
two‑digit number. Not the four (or more future‐proof, five) one
would expect. All the nodes are simply numbered 1 through 99, and then they
start at one again. And shorter is much better:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/02.jpg"
alt="cycling route signage with direction for node 02" width="380" height="214"/>
<cite>source: <a href="http://www.recreatieschapwestfriesland.nl/projecten/fietsroutenetwerk-westfriesland">recreatieschap westfriesland</a></cite>
<p>Two digits is much faster to read and write down. It is easier to memorise,
short‐term. It is instant to compare and confirm. Remember, most of
these actions are performed while riding a bike at a nice cruising speed.</p>
<h4>but…</h4>
<p>Pushing through this two‑digit design must have been asking for
trouble. Most of us can just imagine the bike‐shedding: ‘what if
cyclists really need to be able to uniquely identify a node in the whole
nation?’ Or: ‘will cyclists get confused by these repeating
numbers?’</p>
<p>This older cycling signpost system has a five‑digit identification number:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/mushroom.jpg"
alt="a clycling signpost showing directions to nearby villages and towns"
width="380" height="214"/>
<cite>source: <a href="http://www.dirkdebaan.nl/nooit-meer-fietsend-de-weg-kwijt.html">dirk de baan</a></cite>
<p>This number takes several steps to process. <strong>Two‑digit numbers
are humane numbers</strong>. They exploit that way‐finding is a very local
activity—although one <em>can</em> cover 130km a day on a bike.</p>
<h3>whatchamacallit?</h3>
<p>Wrapping up, the cycling network is a distributed network:</p>
<img class="cited" src="http://mmiworks.net/pics/blog16/nets.jpg"
alt="three graphs: a centralised, a decentralised and a distributed network"
width="380" height="259"/>
<cite>source: <a href="http://j4n.co/blog/progressive_enhancement">j4n</a></cite>
<p>All nodes are equal and so are all routes. Cyclist route themselves.
In that way the network works quite like… the internet.</p>
<p>We could call it the democratic network, because it treats everyone as equals.
Or we could call it the liberal network (that would be very dutch). Or—in
a post‐modern way—we could call it the atomised network.</p>
<p>I simply call it the bicycle route network of the Netherlands.</p>
<img src="http://mmiworks.net/pics/blog16/calf.jpg"
alt="a vista over dutch fields with a calf and two cyclists"
width="380" height="214"/>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-38847775230574214022016-05-30T20:08:00.000+02:002016-05-30T20:09:54.995+02:00designing interaction for creative pros /4<p><span id="teaser">This is the fourth and final part of my
<a href="http://libregraphicsmeeting.org/2015/"><acronym>LGM</acronym> 2015</a>
lecture.</span>
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative.html">Part one</a>
urged to make a clear choice: is the software you’re making is for creative
professionals, or not?
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative_12.html">Part two</a>
was all about the rally car and the need for speed.
<a href="http://blog.mmiworks.net/2015/06/designing-interaction-for-creative.html">Part three</a>
showed the need to support the free and measured working modes of masters.</p>
<p><span id="teaser">Today’s topic is <i>how to be good</i> in
creative‐pro interaction.</span> We start by revisiting the cars of
part two.</p>
<h3>party like it’s…</h3>
<p>It is no coincidence that I showed you a 1991 family car and a 1991 rally car:</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/1991cars.jpg"
alt="pics of the two cars" width="380" height="125"/>
<cite>source: <a href="http://netcarshow.com/audi/1991-100/">netcarshow.com</a>
and <a href="http://imgbuddy.com/audi-quattro-rally-wallpaper.asp">imgbuddy.com</a></cite>
<p>I did that because our world—that of software for creative pros—is
largely stuck in that era. And just like 1991
king‐of‑the‑hill cars (even factory‐mint examples
found in a time capsule), this software is no longer competitive.</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/pants.jpg"
alt="a pair of yellow, y-front underpants" width="380" height="343"/>
<cite>yes, it’s pants! source:
<a href="http://www.charliepants.com/product/y-fronts-sunflower-yellow-main-white-trim">charliepants.com</a></cite>
<p> It is my observation that in this field there is an abundance of
opportunities to do better. If one just starts scratching the surface, on a
product, workflow, or interaction level, then today’s software simply
starts to crumble.</p>
<h4>testing, testing, one two</h4>
<p>For instance, while doing research for the Metapolator project, I asked
some users to show me how they work with the font design tools of today. They showed me
the glyph range, the central place to organise their work and get started:</p>
<img src="http://mmiworks.net/pics/blog14/glyphrange.jpg"
alt="a font editor's table view of all the glyphs in a font"
width="380" height="280"/>
<p>They also showed me the curve editor, where the detailed work on each
glyph is done:</p>
<img src="http://mmiworks.net/pics/blog14/curvedit.jpg"
alt="a big window with a glyph outline editor" width="380" height="231"/>
<p>Both of them need the whole screen. In a short amount of time I saw a lot
of switching between the both of them. I sensed wasted time and broken flows.
I also saw tiny, slow handles in the editor. And I thought: <strong>this
cannot be it</strong>.</p>
<p>They also showed me, in another program, designing in context:</p>
<img src="http://mmiworks.net/pics/blog14/intypo.jpg"
alt="editing a glyph in the context of a few others" width="380" height="236"/>
<p>I immediately sensed this was a big deal. I saw that they had pushed the
envelope—however, not broken through to the other side.</p>
<p>Besides that, I observed that editing was done in outline mode (see the
‘y’, above), but evaluation is of solid black glyphs. Again I
sensed broken flows, because of switching between making and evaluating. And I
thought: <strong>this cannot be it</strong>.</p>
<h3>Frank sez…</h3>
<p>Enough of that; let’s zoom out from my field report, to the big issue
at hand. To paraphrase Zappa:</p>
<blockquote class="hang solo"><em>‘How it has always been’</em> may not be
quite dead, but it sure smells funny.</blockquote>
<p>The question is: how did we get to this situation? Let me dig through my
experience to find some of the causes.</p>
<p>First of all we can observe that each piece of creative‐pro software
is a <strong>vertical market product</strong>; i.e. it is not used by the
general population; only by certain masters. That means <em>we are in
<a href="http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html">armpit of usability</a>
territory</em>. Rereading that blog post, I see I was already knee‐deep
into this topic: ‘its development is driven by reacting to what users
ask for <em>(features!)</em> and fear of changing “like it has always
been” through innovation.’</p>
<h4>go on, have another cake</h4>
<p>The mechanism is clear: users and software makers, living in very different
worlds, have a real hard time communicating. Where they
manage, they are having the wrong conversation: <em>‘gimme more
features!’</em> —‘OK, if that makes
you happy.’</p>
<p>What is happening today is that users are discussing software
made yesterday. They are not able to communicate that their
<em>needs</em> are so lousily addressed. Instead, they <em>want</em> some
more cherries on top and this cements the position of this outdated software.</p>
<p>Constantly, users are telling software makers, implicitly and explicitly,
<strong>‘add plenty of candy, but don’t change
a thing.’</strong></p>
<p>This has been going on for decades—<em>lost decades.</em></p>
<h3>bond of pain</h3>
<p>A second cause that I want to highlight is that both users and software
makers have worked for years to get on the <em>inside</em> and it has been a
really painful experience for all of them. This unites them
against change.</p>
<p>Thus users have been fighting several frustrating years to
get ‘into’ software that was not designed (for them; armpit of
usability, remember), but instead made on terms favourable to the
software makers.</p>
<p>Software makers spent year after year trying to make something useful.
Lacking any form of user research, the whole process has been an exasperating
stab‐in‐the‐dark marathon.</p>
<p>Thus a variant of the Stockholm syndrome spooks both parties. They are
scarred‐for‐life victims of the general dynamic of the
pro‑software industry. But now that they have gotten this far, their
instinct is to sustain it.</p>
<h3>the point</h3>
<p>Two decades of experience shows that there is a way out of this misery; to
become competitive (again). There is no incremental way to get there;
you’ll have to snap out of it. What is called for is innovation—of
your product, workflow, your interaction. A way that unlocks
results is:</p>
<ol>
<li><strong>user research</strong><br/> Experienced researchers cut straight
past the <em>wants</em> and get the user <em>needs</em> on the table.
<i>(Obligatory health & safety notice: market research has nothing to do with
user research; it is not even a little bit useful in this context.)</i></li>
<li><strong>design‐driven innovation</strong><br/>
When user needs are clear (see point 1), then a designer can tell you any
minute of the project—first to last—what part of ‘how it has
always been’ is begging to be replaced, and which part is the solid
foundation to build upon. Designer careers are built on getting this right,
every time.</li>
</ol>
<p>Skip either point—or doing it only in a superficial, or
non-consequential, way—and I’ll guarantee you’ll stay
stuck in 1991. Making it happen requires action:</p>
<blockquote class="solo">Software‐makers: enthusiastically seek out user
researchers and designers and start to sail by them. Stop considering adding
features a good thing, stop being a captive of ‘how it has always
been’ and trust the accomplished.</blockquote>
<h3>picture show</h3>
<p>To illustrate all this, let’s look at some of my designs for
Metapolator. To be able to solve these problems of contemporary font design
tools that I mentioned above, I had to snap out of the old way.</p>
<p>First of all, I pushed <strong>designing in context</strong> a
lot further, by introducing in‑specimen editing:</p>
<img src="http://mmiworks.net/pics/blog14/incontext.jpg"
alt="a pangram type specimen is displayed in a window"
width="380" height="313"/>
<p>Every glyph you see above is directly editable, <strong>eliminating
switching</strong> between overview and editing. The size that the
glyphs are displayed in can be adjusted any given moment, whatever suits the
evaluate/edit balance.</p>
<p class="hang">‘OK, that’s great’ you say, ‘but every
once in a while one needs a glyph range to do some gardening.’ To
address that, I used a handy trick: the <strong>glyph range</strong> is just
another specimen:</p>
<img src="http://mmiworks.net/pics/blog14/inrange.jpg"
alt="the glyph range organised as a specimen" width="380" height="312"/>
<p>Everybody in the Metapolator team thought I was crazy, but I was dead set
on eliminating <strong>outline mode</strong>. I sensed there was chance
to do that here, because the focus moves from working at the edge of the
glyph—the high‐contrast black–white transition—to the
center line within: </p>
<img src="http://mmiworks.net/pics/blog14/bighandles.jpg"
alt="center line displayed within a full-black glyph, the points
on it connected to large handles outside the glyph area"
width="380" height="277"/>
<p>Then there was the matter of offering users <strong>generous handles</strong>
that are fast to grab and use. After brainstorming with Simon Egli, the design
shown above was born: put them ‘on sticks’ outside, so that they
do not impede visual evaluation of the glyph.</p>
<h3>pep talk</h3>
<p><strong>In closing:</strong> <em>to be good</em> in
creative‐pro interaction, I encourage you to—</p>
<blockquote class="solo">Do not ask how the past can guide you.
Ask yourself what <em>you</em> can do to guide your software for
creative pros into the 21st century.</blockquote>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-71616692254862884242016-02-15T12:01:00.000+01:002016-02-15T12:01:51.533+01:00punters vs. society, an illustrated guide<p><span id="teaser">Recently I
<a href="http://blog.mmiworks.net/2015/08/war-and-peace-5th.html">wrote about</a>
how all users act like selfish <em>punters</em> when you talk to them. And
that only user research delivers insight into their diversity and needs,
looking at them as a <em>society</em>. I will illustrate that in this
blog post.</span></p>
<h3>brownie snaps</h3>
<p>Below, we see the users of a product—e.g. a piece of software, an
(internet) service, a device:</p>
<img src="http://mmiworks.net/pics/blog16/punters.png"
alt="32 people distributed in a loose formation."
width="380" height="380"/>
<p>All users are different. Above we see the diversity of this user society
depicted in two dimensions; no two are in the same spot. In reality this spread
happens in dozens of dimensions. Even for very specialised user groups like
‘font designers for indochinese languages,’ there is plenty of
diversity in many dimensions.</p>
<p><em>We all act like selfish punters; you, me, everyone.</em> And
when we are individually engaged in <em>talk</em> about a product,
we will offer self‐centred opinions on what matters most and
self-serving feature requests, i.e. <strong>our wants</strong>:</p>
<img src="http://mmiworks.net/pics/blog16/wants.jpg"
alt="every single person pushes a want that is very different from everybody
else’s." width="380" height="380"/>
<p>The dynamic we see illustrated above is very common in the software industry.
You will find it in 99% of—</p>
<ul>
<li>custom software projects for companies, <acronym>NGO</acronym>s or the
government, during requirements gathering;</li>
<li>small and medium‐sized software companies where the boss, sales, support
and/or consultants talk to customers and users;</li>
<li>any kind of user forum, online or otherwise;</li>
<li>take (a variant of) the second point above and combine it with the
third, that’s <strong><acronym>F/LOSS</acronym>, all of it</strong>;</li>
<li>anywhere where market research is deployed.</li>
</ul>
<h4>write write, scribble scribble</h4>
<p>It is also very common in the software industry to earnestly administrate
user wants:</p>
<img src="http://mmiworks.net/pics/blog16/periphery.jpg"
alt="the wants solidify at the edge of the picture."
width="380" height="380"/>
<p>Common forms of this are—</p>
<ul>
<li>lists of use cases;</li>
<li>use cases in sheep’s clothing: user stories;</li>
<li>bug trackers; not necessarily as an enhancement or a feature request, it
may be dressed up as a bug, or a usability problem;</li>
<li>feature roadmaps;</li>
<li>a lingering pressure, guilt, or fear in the minds of those in
charge—boss, product manager, or maintainer;</li>
<li>a consensus among (part of) the crew: ‘people keep asking for
<acronym>XYZ</acronym>, we could hack something basic in a couple of
days’ <i>(yeah sure)</i>.</li>
</ul>
<p>Now we can compare this administration of wants to the user society:</p>
<img src="http://mmiworks.net/pics/blog16/inside.jpg"
alt="the group of people is framed by the wishes."
width="380" height="380"/>
<blockquote class="solo">We see that <em>at best</em>, wants are good at
describing the fringe of the society, but 80% of them are downright
far‑out and esoteric.</blockquote>
<p>Since wants are so overwhelmingly used in the industry to drive products
and projects, there is overwhelming evidence that this leads to awful results.
It is completely normal that a majority of time and talent is spent on adding
far‑out and esoteric features that are instant bloat.</p>
<p>And thus everybody loses: makers, users and financial backers.</p>
<h3>doing it right</h3>
<p>Now we are going to stop flirting with disaster.</p>
<p>User research avoids all what has been described up to now in this post.
The focus is on—</p>
<ul>
<li>finding out <strong>what users need</strong>;</li>
<li>quality and depth of these findings;</li>
<li>understanding the mechanisms at play.</li>
</ul>
<p>Instead of listening to everbody and their dog, researchers accompany a
selection of representative participants on a ‘journey‘ through
the pertaining activity, while constantly picking their brain:</p>
<img src="http://mmiworks.net/pics/blog16/interview.jpg"
alt="six paths run through the group of people, mostly concentrated in the
middle, some parts fly further out." width="380" height="380"/>
<p>Above, we see depicted that when users still <em>insist</em> on pushing
their wants (i.e. go far out), researchers reel them in by questioning;
peeling away layers of rationalisation in order to understand the
underlying needs.</p>
<p>These needs are not exotic, they are basic human needs (e.g. control,
overview, feedback, organisation, a stable environment, a simple rule book)
that form the center of the picture—and are central to making it work
for users.</p>
<p>Researchers and designers collaborate on constructing a model—an
understanding—of the user society. The centre of the picture is where one
finds the commonalities in the (analysed) research material:</p>
<img src="http://mmiworks.net/pics/blog16/heart.jpg"
alt="a cloud coincides with the density of the six paths."
width="380" height="380"/>
<p>This is <em>the heart of the matter</em>. It is surrounded by the diversity
in needs as found by the research. Note that there is a hard edge to this
model: what is outside is certainly out of scope.</p>
<p>The qualitative aspect of research (e.g. taking into account the tone of
voice or facial expression when something is stated) makes a world of
difference. It is this richness of information that makes user research so
effective. We see above that some outliers have been ignored in the user
model. This is done with full confidence, based on the research.</p>
<h4>core, non‑core</h4>
<p>Now we can compare the needs‐based user model to the user
society:</p>
<img src="http://mmiworks.net/pics/blog16/coverage.jpg"
alt="the could of needs hides most of the people."
width="380" height="380"/>
<p>The coverage of the model works out so well, that it is difficult to see
the actual users. This is especially true for the heart of the matter. Note
that some users at the very fringe of society may <em>feel</em> left out; they
are covered a little bit or not at all.</p>
<p>In a design‐driven approach, the needs‐based user model is used
to decide which features to add (cover the diversity, but nothing beyond the
edge) and where to focus design and development effort (on the heart of
the matter).</p>
<h3>A/B testing</h3>
<p>Zooming out, we now can compare the two approaches:</p>
<img src="http://mmiworks.net/pics/blog16/compare.jpg"
alt="the frame of wants around the cloud of needs"
width="380" height="380"/>
<p>When compared to the results of user research, the bog standard, wildly
popular method of <strong>listening to users and
their wants</strong>—</p>
<ul>
<li>fails to record the heart of the matter;</li>
<li>fails to record the diversity of user needs;</li>
<li>is a list of disparate wishes, instead of a coherent, nuanced insight;</li>
<li>highlights the fringe, the far‑out, the esoteric;</li>
<li><strong>gets you completely the wrong picture.</strong></li>
</ul>
<p></p>
<h4>postscript</h4>
<p>This past semester I discussed all this with my students at the
<a href="http://www.btk-fh.de/en/"><acronym>BTK</acronym> design school</a>.
To get the point across about the dangers of talking to users, I asked them
‘do you remember these creatures in mythology that always give you the
wrong answer, so that you get lost?’</p>
<p class="hang">‘Yeah’, they said, ‘they are
called trolls.’</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-21091374394498806672015-08-21T10:22:00.000+02:002015-08-21T10:22:24.937+02:00war and peace—the 5th column<p><span id="teaser">Building out the
<a href="http://blog.mmiworks.net/search/label/war%20and%20peace">war and peace series</a>,
this second instalment focusses on acts of sabotage performed by users
against… users. For those in a hurry, there is a
<a href="#inshort">short, sharp summary</a> at the end.</span></p>
<h3>cuckoo</h3>
<p>Last week my friend <a href="https://twitter.com/jancborchardt">Jan‑C. Borchardt</a>
<a href="https://twitter.com/jancborchardt/status/630744332836950016">tweeted</a>:</p>
<blockquote class="solo hang">‘Stop saying »the user« and referring to
them as »he«. Thanks!’</blockquote>
<p>To which I replied:</p>
<blockquote class="hang">‘“They”; it is always a group,
a diverse group.</blockquote>
<blockquote class="solo hang">‘But I agree, someone talking about
“the user” is a tell‐tale sign that they are part of the
problem, not the solution.’</blockquote>
<p>All that points at a dichotomy that I meant to blog about for a long
time. You see,
<a href="http://blog.mmiworks.net/2013/10/war-and-peace-abridged-ui.html">part one</a>
of the war and peace series looked at all four parties involved—product makers,
users, developers and designers—as separate silos. The logical
follow‑up is to look at <strong>hybrid actors</strong>: the
user‐developer, the product maker‐developer, et cetera.</p>
<p>While working to provide a theoretical underpinning to 20+ years of
observation of performance <em>in practice</em> of these hybrid actors,
I noticed that for <em>all</em> user‐<acronym>XYZ</acronym>
hybrids, the <em>user</em> component has not much in common with the
<em>users</em> of said product. In general, <strong>individual users are in
conflict with the user group they are part of</strong>.</p>
<p>That merits its own blog post, and here we are.</p>
<h3>spy vs. spy</h3>
<p>First we got to get away from calling this ‘user versus
users.’ The naming of the two needs to be much more dissimilar, both to
get the point across and so that you don’t have to read the rest of
this post with a magnifying glass, just to be sure which one I am
talking about.</p>
<p>During the last months I have been working with the concept of
<strong>inhabitants vs. their city</strong>. The inhabitants stand for
individual users, each pursuing their personal interests. All of them are
united in the city they have chosen to live in—think photoshop city,
gmail city, etc. Each city stands for a bustling, diverse user group.</p>
<h4>inner city blues</h4>
<p>With this inhabitants & city model, it becomes easier to illustrate the
mechanisms of conflict. Let’s start off with a real‐life example.</p>
<p>Over the next years, Berlin needs to build tens of thousands units of
affordable housing to alleviate a rising shortage. Because the tens of
thousands that annually move to Berlin are (predominantly) looking for its
bubbly, relaxed, urban lifestyle, building tower blocks on the edge of town
(the modernist dream), or rows of cookie‐cutter houses in suburbia (the
anglo‐saxon dream) won’t solve anything.</p>
<p>What is needed is development of affordable housing in the large urban
area of Berlin. A solid majority of the population of Berlin agrees with this.
Under one condition: no new buildings in <em>their</em> backyard. And thus almost
nothing affordable gets built.</p>
<p>What can we learn from this? <strong>Naturally reactionary inhabitants
take angry action to hinder the development that their city really needs.</strong>
I am sure this rings a bell for many a product maker.</p>
<h4>yee‑haw!</h4>
<p>The second example is completely fictional. A small posse of inhabitants
forms and petitions the city to build something for their <em>(quite)</em>
special interest: a line‐dancing facility. At first they demand that
the city pays for everything <strong>and</strong> performs all the work. When
this falls on deaf ears, the posse organises a kickstarter where about
150 backers chip in to secure the financing of the
building work.</p>
<p>Being petitioned again, the city asks where this line‐dancing
facility could be located. The posse responds that in one of the nicest
neighbourhoods there is a empty piece of grassland. The most accessible part
of it would be a good location for the facility and its parking lot.</p>
<p>The city responds that this empty grassland host events and community
activities on about 100 days a year, many of which are visited by folks from
all over the city. And all other days of the year the grassland serves the
neighbourhood, simply by being empty and semi‐wild nature; providing a
breather between all the dense and busy urbanisation, and a playground
for kids.</p>
<h4>repeat after me: yee‑haw!</h4>
<p>This angers the line‐dancing posse. They belittle the events and
activities, and don’t know anyone who partakes in them. The events can
be moved elsewhere. The land just sits there, being empty, and is up for
grabs. Here they are with a sack of money and a great idea, so let’s
get a move on.</p>
<p>The city then mentions one of its satellite towns, reachable by an
expressway. At its edge, there is plenty of open space for expansion. It would
be good to talk to the mayor of that town. The posse is now furious. Their
line‐dancing facility, which would make such a fine feature for the
heart of the city, being relegated to being an appendix of a peripheral
module? <em>Impossible!</em></p>
<p>What can we learn from this? <strong>Inhabitants will loudly push their
special‐interest ideas, oblivious to the negative impact on their
city.</strong> Again this must also ring a bell for many product makers.</p>
<h3>leaving the city</h3>
<p>Now that the inhabitants & city model has helped us to find these
mechanisms, I must admit there are also some disadvantages to it.
First, cities do not scale up or down like user groups do. I have worked
on projects ranging from a handful of users (hamlet) to 100 million
(large country). And yes, the mechanisms hold over this range.</p>
<p>Second, I suspect that many, especially those of a technological
persuasion, will take the difference between inhabitants and their city to be
that the former are the people, and the latter the physical manifestation,
especially buildings and infrastructure.</p>
<h4>no escape</h4>
<p>Thus we move on for a second time, picking a more generic route, but one
with <em>attitude</em>. For <em>individual users</em> I have picked the term
<strong>punter</strong>. If that smacks to you as <i>clientèle</i> that is
highly opinionated, with a rather parochial view of their environs, then you
got my point.</p>
<p>Now you may think ‘is he picking on certain people?’ No, on
the contrary: <strong>we all are punters</strong>, for everything we use:
software, devices, websites, services—hell, all products. You, <em>me</em>,
everyone. We are all just waffling in a self‐centred way.</p>
<p>There is no single exception to the <em>punter principle</em>, even for
people whose job is centred on getting beyond the punter talk and to the
heart of the matter. It is simply a force of nature. The moment we
touch, or talk about, a product we use, we are a punter.</p>
<h4>greater good</h4>
<p>For the <em>user group</em> I have picked the term
<strong>society</strong>. This works both as a bustling, diverse populace and
as a club of people with common interests (the photoshop society, gmail
society, product‑<acronym>XYZ</acronym> society). Some of you,
especially when active in <acronym>F/LOSS</acronym>, will say ‘is not
community the perfect term here?’ It <em>would</em> be, if it
wasn’t already squatted.</p>
<p>After almost a decade in
<acronym>F/LOSS</acronym> I can say that in practice,
<em>‘community’ boils down to a pub full of punters</em> (i.e.
chats, mailing lists and forums). In those pubs you will hear punters yapping
about their pet feature (line dancing) and loudly resisting structural change
in their backyard. What you won’t hear is a civilised, big‐picture
discourse about how to advance their society.</p>
<h4>it differs</h4>
<p>One thing that last week’s exchange with Jan‑C., and also a follow
up <a href="https://plus.google.com/+petersikking/posts/Zv4uQCtF3WX">elsewhere</a>,
brought <em>me</em> is the focus on the <strong>diversity</strong> of a
(product) society. This word wonderfully captures how in dozens and dozens of
dimensions people of a society <strong>are</strong> different, have different
needs and different approaches to get stuff done.</p>
<p>I can now review my work over the last decade and see that diversity
is a big factor in making designing for users so demanding. The challenge is
to create a compact system that is flexible enough to serve a diverse society
(hint: use the common interests to avoid creating a sprawling mess).</p>
<p>I can also think of the hundreds of collaborators I worked with and now
see what they saw: diversity was either ‘invisible,’ in their
mono‐cultural environment, or it was such an overwhelming problem that
they did not dare tackle it (‘let’s see what the user asks
for’). <strong>Talking about ‘the user’ is the
tell‐tale sign of a diversity problem.</strong></p>
<p>The big picture emerges—</p>
<blockquote class="solo">If you want to know why technology serves society
so badly, look no further than the tech industry’s problem to acknowledge,
and adapt to, the diversity of society.</blockquote>
<p>Yes, I can see how the tendency of the tech sector to make products that
only its engineers understand has the same roots as the now widely publicised
problem that this sector has a hard time being inclusive to anyone who is not
a male, <acromnym>WASP<acromnym> engineer; <em>it is a diversity
problem.</em></p>
<h3>but why?</h3>
<p>Back to the punters. That we all act like one was described ages ago by
<a href="https://en.wikipedia.org/wiki/Tragedy_of_the_commons">the tragedy of the commons</a>.
This is—</p>
<blockquote class="solo hang">‘[…] individuals acting
independently and rationally according to each’s self‐interest
behave contrary to the best interests of the whole group by depleting some
common resource.’</blockquote>
<p>If you think about it for a minute, you can come up with many, many
examples individuals acting like that, at the cost of society. The media
are filled with it, every day.</p>
<h4>what a waste</h4>
<p>What common resources do punters strive to deplete in (software) products?
From my position that is easy to answer—</p>
<ol>
<li><strong>makers’ time</strong>; both in proprietary and
<acronym>F/LOSS</acronym>, the available time of the product maker, the
designer and developers is <em>scarce</em>; it is not a question of money, nor
can you simply throw more people at it—larger teams simply take longer to
deliver more mediocre results. To make better products, all makers need to be
focussed on what can advance their society; any time spent on punter talk, or acts
(e.g. a punter’s pull request), is wasted time.</li>
<li><strong>interaction bandwidth</strong>; this is, loosely, a combination
of UI output (screen space, sound and tactile output over time) and input
(events from buttons, wheels, gestures), throttled by the limit what humans
can process at any given time. Features need interaction and this eats the
available bandwidth, fast. In good products, the interaction bandwidth is
allocated to serve its whole society, instead of a smattering of punters.</li>
</ol>
<p>The tragedy of (software) products is that it’s completely normal that in
reaction to punters’ disinformation and acts of sabotage, a majority of
maker’s time and a majority of interaction bandwidth gets wasted.</p>
<p>Acts of sabotage? <acronym>SME</acronym> software makers of specialised
tools know all about fat contracts coming with a list of punter wishes. Even
in <acronym>F/LOSS</acronym>, adoption by a large organisation can come with
strings attached. Modern methods are trojan horses of punter‐initiated
bounties, crowdfunding or code contributions of their wishes.</p>
<h3>the point</h3>
<p>This makes punters the
<a href="https://en.wikipedia.org/wiki/Fifth_column">fifth column</a> in the
UI version of war and peace. Up to now we had four players in our
saga—product maker, users (i.e. the society), developers and the
designer—and here is a fifth: <strong>a trait in all of us</strong>
within society to say and do exactly that what makes (software) products
bloated, useless, collapse under their own weight and burn to the ground.</p>
<p>It is easy to see that punters are the enemy of society and of product
makers (i.e. those who aim to make something really valuable for society).
Punters have an ally in developers, who love listening to punters and then
build their wishes. It makes the both of them feel real warm and fuzzy.
<i>(I am still not decided on whether this is deliberate on the part of
developers, or that they are expertly duped by punters offering warmth and
fuzziness.)</i></p>
<p>That leaves designers; do they fight punters like dragon slayers? No, not
at all. Read on.</p>
<h4>the dragon whisperer</h4>
<p>Remember that punters and society are one and the same thing. The trick is
to attenuate the influence of punters to zero; and to tune into the diversity
and needs of society and act upon them. Problem is, you only get to talk to
punters. Every member of society acts like a punter when they open
their mouth.</p>
<p>There is a craft that delivers insight into a society, from working with
punters. It is called <strong>user research</strong>. There are specialist
practitioners (user researchers) and furthermore any designer worth their
salt practices this. There is a variety of user research methods, starting
with interviewing and surveying, followed up by <em>continuous analysis</em>
by the designer of <em>all</em> punter/society input (e.g. of all that
‘community’ pub talk).</p>
<h4>the billion‐neuron connection</h4>
<p>What designers do is maintain a model of the diversity and needs of the
society they are designing for, from the first to the last minute they are on
a project. They use <em>this</em> model while solving the
product‐users‐tech puzzle, i.e. while designing.</p>
<p>When the designer is separated from the project (tech folks tend towards
that, it’s a diversity thing) then the model is lost. And so is
the project.</p>
<p><i>(Obligatory health & safety notice: market research has nothing to do
with user research, it is not even a little bit useful in this context.)</i></p>
<h3>brake, brake</h3>
<p>At this point I would like to review the conflicts and relationships that
we saw in
<a href="http://blog.mmiworks.net/2013/10/war-and-peace-abridged-ui.html">part one</a>
of war and peace, using the insights we won today. But this blog post is already
long enough, so that will have to wait for another day.</p>
<p id="inshort">Instead, here is the short, sharp summary of this post:</p>
<ul>
<li>Users groups can be looked at in two ways: as a congregation of <em>punters</em>
and as a <em>society</em>.</li>
<li>We all are punters, talking in a in a self‐centred way and acting in
our self‐interest.</li>
<li>We are also all members of (product) societies; bustling, diverse populaces
and clubs of people with common interests (the photoshop society, gmail
society, product‑<acronym>XYZ</acronym> society).</li>
<li>Naturally reactionary punters take angry action to hinder structural
product development.</li>
<li>Punters will loudly push their special‐interest ideas, oblivious to
the negative impact on their society.</li>
<li>The diversity of societies poses one of the main challenges in designing
for users.</li>
<li>The inability of the tech sector to acknowledge, and adapt to, the
diversity of society explains why it tends to produce horrible,
tech‐centric products.</li>
<li>In a fine example of ‘the tragedy of the commons,’ punters
behave contrary to the best interests of their society by depleting
makers’ time and interaction bandwidth.</li>
<li>Punters act like a fifth column in the tri‑party conflict between
product makers, society and developers.</li>
<li>You only get to talk to punters, but pros use user research methods to
gain insight into the diversity and needs of a society.</li>
<li>Everyone gets bamboozled by punters, but not designers. They use user
research and maintain a model of diversity and needs, to design
for society.</li>
</ul>
<p>Interested, or irritated? Then (re)read the whole post before commenting.
Meanwhile you can look forward to part three of war and peace, the
UI version.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-40025967787987039092015-08-07T13:31:00.002+02:002015-08-07T13:31:43.740+02:00wishful thinking; ignite the shirts<p><span id="teaser">A week ago I presented about my
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thinking</a>
and
<a href="http://blog.mmiworks.net/search/label/act%20to%20succeed">act to succeed</a>
series at <a href="http://igniteberlin.com">Ignite Berlin</a>. That led to
some unforeseen developments, with the result that you can look forward to
some real cool t‑shirts.</span></p>
<h3>kaboom!</h3>
<p>The Ignite format is pretty demanding. I better let them explain it
themselves:</p>
<blockquote class="hang">‘Each speaker gets 5 minutes on stage.
20 slides, which auto‐forward every 15 seconds, no going back. So
it’s pretty brutal, although nothing that a rehearsal
can’t fix.’</blockquote>
<cite>the Ignite format, from
<a href="http://igniteberlin.com/briefly-ignite/">their about page</a></cite>
<p>Yes, this is really different than presenting 20 to 45 minutes at your
own rhythm, which is what I am used to. A strategy, careful planning of the
20 slides and a generous helping of rehearsal are asked for. What I
regularly see at conferences—some (recycled) slides banged together the
night before and winging it during showtime—is bound to have a 99.99%
fail rate at Ignite.</p>
<h4>bang, you win</h4>
<p>The upside is that the audience wins. All the speakers are an order of
magnitude more prepared than they normally would be. There is no time for
waffling and even single‐issue talks are engaging for five minutes.</p>
<p>At this event there were fourteen talks, two runs of seven each, which
sounds like a <em>looong</em> marathon to sit through. In praxis, one run of
seven talks takes 35 minutes of pure talk time, plus some for applaus and
changeover (everything is pre‐sequenced on a single laptop). Thus in
38–40 minutes, seven engaging topics have passed and then it is
time for a break, to digest and discuss.</p>
<p>Since my talk was scheduled almost at the end of the event,
I expected to be too preoccupied to enjoy all these talks before mine. On
the night, <em>all</em> of the talks engaged and entertained me, which put me
in a good mood for mine. <i>(When is the last time you could say that about
a conference?)</i></p>
<h3>show and tell</h3>
<p>In my Ignite talk I showed a selection of wishful‐thinking issues,
<a href="http://blog.mmiworks.net/search/label/act%20to%20succeed">together with the positive action</a>
that <strike>can</strike> must be taken to remedy them. Meanwhile, I told
the back‐story, for instance, that—</p>
<ul>
<li>I have <em>seen</em> all of this wishful thinking in practice;</li>
<li>I wanted to expose a destructive streak that runs through the
<acronym>IT</acronym> industry;</li>
<li>it was more work to make issues and remedies fit a single tweet, than to
come up with them;</li>
<li>I felt that I could go on ‘forever’, but called it
quits at fifty;</li>
<li>being in interaction design—which is essentially product realisation
and involves seeing <strong>all</strong> dimensions (product, users,
tech)—makes it easy to see the damage from wishful thinking;</li>
<li>it is a real shame to see the right people, with the right intentions,
run projects into the ground through wishful thinking;</li>
<li>this is not valid only in <acronym>IT</acronym>, but in any industry;</li>
<li>please, it is difficult, but resist the wishful thinking when you believe
in what you are working on;</li>
<li>what is needed is process change, which is also difficult, introducing a
design process that from the first to the last minute of the project shapes
and runs all product realisation, including manufacturing or fixing that
final bug.</li>
</ul>
<h4>aftermath</h4>
<p>I had plenty of interesting discussions after the talks were through, but
one really took me by surprise: fellow speaker
<a href="http://igniteberlin.com/2015/07/20/onika-simon/">Onika Simon</a> of
<a href="http://spokehub.org/">Spokehub</a> said something along the lines of
‘why don’t you put this wishful thinking on t‑shirts?
There are plenty of people who deserve to get one.’</p>
<p>During my talk I had admitted that I am not a product maker and that never
in my life I’ve had a good product idea. Thus it did not surprise me that I
never had thought of wishful‐thinking t‑shirts. But now that the
genie was out of the bottle, how difficult could it be?</p>
<h4>snakes and ladders</h4>
<p>Some parts <em>were</em> really straightforward. The content was already
there. Deciding what should go on front and back, and picking some
free‐as‐in‐speech fonts (right, no pirated components in
<em>my</em> products) was no big deal. Neither was typesetting
the texts.</p>
<p>Making <acronym>EPS</acronym> files already involved jumping through one hoop
(why not accept pdf? It is just about the same tech). Dealing with spreadshirt
was a three‐ring circus. Spreadshirt is suppose to make it easy to open
your own merchandising outlet, but forget about the easy part.</p>
<p>I could go on and on, about requiring flash <spit>, crashes, usability
disasters, the pervasive ‘how do I get that done?’ and ‘how
do I know it did it?’ anxiety, and only finding out what you will get when
you get there. But let’s say that unless you are a spreadshirt executive,
I won’t bother (you with it).</p>
<h3>lift‑off</h3>
<p>Against these odds, I did manage to put up
<a href="http://shop.spreadshirt.de/mmiworks">a t‑shirt shop</a>
in less than a week. <strong>There is one <acronym>MVP</acronym></strong>: a
limited‐edition t‑shirt (available one month <em>only</em>) in
female and male cuts, and two variants, dark and bright:</p>
<a href="http://shop.spreadshirt.de/mmiworks">
<img src="http://mmiworks.net/pics/blog14/4shirts.jpg"
alt="the bright female, dark female, dark male and bright male wishful
thinking shirts" width="380" height="89"/></a>
<p>I found out at the <em>very end</em>, when I got to check it out
(typical, eh), that you can change the shirt colour in the shop.
Suits me fine; a simple ‘menu’ to choose from and then freedom to
customise, a bit.</p>
<p>When I checked the
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thinking</a>
topic page, I noticed how hard‐hitting these are by themselves, so it
was clear that these go, solo, on the front:</p>
<a href="http://shop.spreadshirt.de/mmiworks">
<img src="http://mmiworks.net/pics/blog14/shirtfront.jpg"
alt="the text on the front of the shirt: the hardware specs are fixed, now
we can start with the software design" width="380" height="425"/></a>
<p>This is the wishful thought for August ’15 and you can see that
I plunged for the first one I saw. Each month I will pick a different one (no,
not in the order on that page) and change the ‘bright’
colour scheme.</p>
<p>On the back we ensure that everyone gets the point…</p>
<a href="http://shop.spreadshirt.de/mmiworks">
<img src="http://mmiworks.net/pics/blog14/shirtback.jpg"
alt="the text on the back: wishful thinking breeds failed products"
width="380" height="428"/></a>
<p>…just in case the beholder wishfully thinks the statement on the front
<strong>is</strong> best‐practice.</p>
<h4>postscript</h4>
<p>And out of the blue m+mi works offers a hardware product. It will be
fun offering these and I hope spreadshirt cooperates a bit more to keep it
that way. I look forward to seeing one of these t‑shirts being worn
in the wild.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-42570260746317424622015-06-23T09:24:00.000+02:002015-06-24T09:25:25.619+02:00designing openType‐features UI /intro<p><span id="teaser">This blog post kicks off my involvement with bringing
openType features to <acronym>F/LOSS</acronym> (typo‐)graphical
software. I will explain why this is a special, complicated project,
followed by the approach and structure I will apply to this design project
and finish with what to expect as deliverables.</span></p>
<h3>a bit of a situation</h3>
<p>First things first. It is quite likely that when you are reading this, you
know what openType features in fonts are. But just in case you don’t,
here is a
<a href="http://typofonderie.com/font-support/opentype-features/">friendly, illustrated explanation</a>
of <em>some</em> of the features, without putting you straight into
<a href="http://partners.adobe.com/public/developer/opentype/index_tag3.html">corporate specification hell</a>.
The reason I said ‘some’ will become clear below.</p>
<p>What is interesting is that <em>there is a riot going on.</em> The
800‑pound gorillas of (typo‐)graphical software—the
adobe creative suite applications—have such bad and disparate UI for
handling openType features that a grass‐roots protest movement started among
typographers and font designers to do something about it. What followed was a
<a href="http://ilovetypography.com/2014/10/22/better-ui-for-better-typography-adobe-petition/">a petition</a>
and a hasty promise by adobe to do better—in the future.</p>
<h4>meanwhile in Toronto…</h4>
<p>These events prodded Nathan Willis into action, because
‘open‐source applications aren’t any better in this
regard.’ He organised a openType workshop at
<a href="http://libregraphicsmeeting.org/2015/">this year’s <acronym>LGM</acronym></a>
to get a process started to change that. I went there because this is smack
in the middle of one of my fields of specialisation: interaction for creatives. As you can read in
<a href="http://www.freesoftwhere.org/2015/05/07/opentype-workshop-lgm-2015/">Nathan’s report</a>,
I got immediately drawn into the UI discussion and now we have a
loose‐knit project.</p>
<p>The contents and vibe of the questions, and my answers, in the
UI discussion all pointed in a certain direction, that I was only able to
name a day later: harmonised openType features for <em>all</em>
<acronym>F/LOSS</acronym> (typo‐)graphical applications definitely has
an <strong>infrastructure component</strong>.</p>
<h3>the untouchables</h3>
<p><em>Pure</em> infrastructure—e.g. tap water, electricity,
telecoms—offers its designers some unique challenges:</p>
<dl>
<dt>everybody uses it</dt>
<dd>and everybody’s needs are equally important; there is no opportunity
to optimise the design for the specific needs of user groups.</dd>
<dt>nobody cares</dt>
<dd>usage is ubiquitous, i.e. we all do not even register that we are using
this stuff all the time—until it stops working, then we miss it
a hundred times a day. This makes it very hard to research; no recollection,
feelings or values are connected to infrastructure, just entitlement.</dd>
<dt>anyplace, anywhere, anytime</dt>
<dd>there is no specific contextual information to work with: why is it used;
what is the goal; what does it mean in the overall scheme of things; how much
is a little, and a lot; it is used sparsely, all the time, at regular
intervals, in bursts? It all depends and it all happens. Just deal with it,
all of it.</dd>
<dt>millions of use cases</dt>
<dd><i>(not that I consider use cases a method that contributes positively to
any software project, but‐)</i> in the case of infrastructure something
funny and instructive happens: after a week or two of exploration and mapping,
the number of use cases grows exponentially towards a million and… keeps on
growing. I have seen this happen, it is like peeling an onion and for
every layer you peel off, the number goes up by an order of magnitude. These
millions of use cases are an expression of <em>everybody</em> using it
<em>anyplace, anywhere, anytime</em>.</dd>
<dt>heterogeneous capabilities</dt>
<dd>this is not always the case, but what is available <em>can</em>
vary, a lot. For instance public transport: how many connections (incl. zero)
are available for a given trip—and how fast, frequent and comfortable
these are—is set by the network routes and timetables. An asked‑for
capability is on offer, or not. It all depends and it all happens. Just deal
with it, all of it.</dd>
</dl>
<p>I have worked as design lead on two infrastructure projects. One was
<a href="http://mmiworks.net/portfolio/index.html#dualSIM">Nokia dual‑<acronym>SIM</acronym></a>,
the other
<a href="http://blog.mmiworks.net/search/label/openPrinting">openPrinting</a>,
where we designed printing dialogs for all linux users <i>(everyone)</i>, as
used in 10.000 applications <i>(anyplace, anywhere, anytime)</i>, connected to
10.000 different printer models <i>(heterogeneous capabilities)</i>. I dubbed
it the project with five <i>million use cases</i>.</p>
<p>Ah, and since both application and printer configure the available options
of the print dialog, there are potentially 100 million configurations.
Even if in reality the variability is <em>far</em> less (say, just 1% on both
application and printer side; i.e. 100 significantly different printer models
and 100 apps that add serious, vital printing options), then it is still
an overwhelming 10.000 configurations.
<h4>drowning, not waving</h4>
<p>In my experience, designing infrastructure is very demanding. All the time
one switches between making the big, abstract plan for
<em>everything</em>, and designing, minutely, one of many details in complete
isolation. Mid‑level interaction design, the journeyman,
run‑of‐the‑mill, lay‑out‐a‑screen level,
is completely missing.</p>
<p>It is like landscaping a featureless dessert, where every grain of sand is
a detail that has to be dealt with. With no focus on particular users, no
basis for research, no context, no
just‑design‐<em>the</em>‐example, millions of use cases and
highly variable capabilities, I have seen very capable design colleagues
lose their bearings and give up.</p>
<h3>back at the ranch</h3>
<p>Enough war stories. How large is this infrastructure component of openType
features in (typo‐)graphical software? Let’s check the list:</p>
<ul>
<li><strong>everybody uses it</strong>—nope. Whether the user groups
turn out to be defined real narrow or quite wide—a matter of
<a href="#vision">vision</a>—they will have in common that all of them
know their typesetting. That is a craft, not common knowledge.</li>
<li><strong>nobody cares</strong>—well, soon they won’t. Right now
there is upheaval because nothing is working. As soon as users get a working
solution in the programs they use, it will become as interesting as the
streetlights in your street.</li>
<li><strong>anyplace, anywhere, anytime</strong>—right on! This has to
work in (typo‐)graphical software; all of it—even the kind I have
never heard of, or that will be invented in five years from now. All we know,
is that serious typesetting is performed there by users, on any length of text
selection.</li>
<li><strong>millions of use cases</strong>—not quite. The limited user
group provides the breaks here. But there is no such limit from the
application side; on the contrary: most of these are (open‐ended) tools
for creatives. Just thinking about how flexible a medium text is, for
<a href="http://blog.mmiworks.net/2012/05/rethinking-text-handling-in-gimp-1.html#dual">information or shapes</a>,
gives me the confidence to say that 10.000 use cases could be compiled, if
someone would sit down and do it.</li>
<li><strong>heterogeneous capabilities</strong>—hell yeah!
OpenType‐features support in fonts is all over the place and not just
because of negligence. First there is the kaleidoscopic diversity of scripts
used around the world, most of which you and I have never heard of. Latin
script is just the tip of the iceberg. Furthermore, what is supported, and how
each supported feature is actually realised, is completely up to the font
designer. The openType‐features standard is open‐ended and creates
opportunities for adding sophistication. This is only limited by the combined
imagination of the font design community.</li>
</ul>
<p>Adding that up, we get a score of 3½ out of 5. By doing this exercise
I have just found out that openType features in (typo‐)graphical
software is 70% infrastructural. This is what I meant with that it is a
special, complicated project.</p>
<h3>structure—the future</h3>
<p>In projects like these structuring the design work is
make‑or‐break; either we set off in the right direction, or never get
to <em>any</em> destination—not even a wrong one. The structure I use is
<a href="http://mmiworks.net/wedo/product.html">no secret</a>.
Here is my adaptation for this project:</p>
<p id="vision">A <strong>product vision</strong> is not that easy to formulate
for pure infrastructure; it tends to shrink towards ‘because it’s
there.’ For instance at openPrinting the vision was ‘printing that
just works.’ I still regret not having twisted some arms to get a
value statement added to that. There were times that this value void was
keeping us from creating true next‐generation solutions.</p>
<p>Apart from ‘what’s the value?’ also ‘who is this
for?’ needs to be clarified; as we saw earlier, openType features is not
for everyone. The identity question, ‘what is it we are making?’
may be a lot less spectacular, but it needs to be agreed. I will take
this to the
<a href="http://lists.freedesktop.org/mailman/listinfo/create">Create mailing list</a>
first, mainly to find out who are the ‘fish that swim upfront’,
i.e. the people with vision and drive. Step two is an online vision session,
resulting in a defined vision.</p>
<p>The deliverable is a to‑the‐point vision statement. If you want
to get a good picture of what that entails, then I recommend you read this
<a href="http://blog.mmiworks.net/2014/04/writing-product-vision-for-metapolator.html">super‐informative blog post</a>.
Bonus: it is completely font‐related.</p>
<h4>we want the funk, the whole funk, nothing but the funk</h4>
<p>A deep understanding of the <strong>functionality</strong> is the key to
success in this project. I already got burned once with openType features
in the <a href="http://blog.mmiworks.net/search/label/metapolator">Metapolator</a>
project. Several font designers told me: ‘it is only a bunch of
substitution rules.’ Until it turned out it isn’t. Then at the
<acronym>LGM</acronym> meeting another surprise complication surfaced. Later I
briefly check the specification and there is yet another.</p>
<p>This is what I meant before with that
<a href="http://typofonderie.com/font-support/opentype-features/">friendly page</a>
explaining <em>some</em> of the features. I do not trust it to be
complete (and it is only Latin‐centric, anyway). As interaction
architect I will have to be completely on top of the functionality, never
having to rely on someone else to explain me what ‘is in the box.’
This means knowing the openType standards.</p>
<p>Central to it is the feature tags specification and the feature definition
syntax. This contains both the material for understanding of how complicated
it <em>all</em> can get and the structures that I can use to formulate
UI solutions. It is one of the few aspects that are firm and finite in
this project.</p>
<p>The deliverable is a functionality overview, written up in the
project wiki.</p>
<h4>talking heads</h4>
<p>I will do <strong>user research</strong>, say interview half a dozen users,
to gain insight into the act of typesetting, the other aspect that is firm and
finite in this project. Which users to recruit depends on what is defined in
the product vision. Note that the focus is on <em>the essence</em> of
typesetting, while ignoring its specific role in the different
(typo‐)graphical applications, and not get swamped by the latter’s
diversity.</p>
<p>The deliverable is notes of interest from the interviews, written up
in the wiki.</p>
<p>I look forward to an <strong>exchange with</strong>
<acronym>F/LOSS</acronym> (typo‐)graphical <strong>applications</strong>
via the Create list. This is not intended to get some kind of inventory of all
the apps and how different they are. In this project that is taken as abstract
and infinite—the good old infrastructural way.</p>
<p>What I want to find out is in how many different ways openType features
must, or can, be integrated in the UIs of (typo‐)graphical applications.
In blunt terms: how much space is there available for this stuff, what shape
does it have and what is the duty cycle (permanently displayed, or a
pop‑up, or…)? These diverse application needs are clustered into
<em>just</em> enough <strong>UI models</strong> (say, six) and
used below.</p>
<p>The deliverable is the UI models, written up
in the wiki.</p>
<h4>getting an eyeful</h4>
<p>Then it is time to do an <strong>expert evaluation</strong> of existing
openType‐features UI and all these UI ideas offered by users when the
petition did its rounds. All of these get evaluated against—</p>
<ul>
<li>the product vision: does it realise the goals? Is it appropriate for the
defined user groups?</li>
<li>the functionality: can it cope with the heterogeneous capabilities?</li>
<li>the user research: how tuned is it for the essence of typesetting?</li>
<li>the UI models: how well does it fit with each model?</li>
</ul>
<p>All of it gets analysed, then sorted into the good, the bad and the ugly.
There will be a tiny amount of gold, mostly in the form ideas and
intentions—not really what one would call a design—and a large
catalog of what exactly <strong>not</strong> to do.</p>
<p>The deliverable is notes of interest from the evaluation, written up
in the wiki.</p>
<h4>warp drive</h4>
<p>Then comes the moment to stop looking backwards and start working forwards;
to start creating the future. First a <strong>solutions model</strong> is
made. This is a combination of a broad‐strokes solution that cuts the
project down to manageable proportions and a defined approach how to deal with
the rest, the more detailed design work.</p>
<p>The next stage is to design a <strong>generic solution</strong>, one that
already deals with all of it, all the hairy stuff: text selections of any
length, all the heterogeneous capabilities, the typesetting workflow, clear
representation of all openType features available and their current state.
This will be specified in a wiki, in the form of UI patterns.</p>
<p>With the generic solution in place it will be real clear for the central
software library in this small universe, HarfBuzz, which new capabilities it
will need to offer to <acronym>F/LOSS</acronym> (typo‐)graphical
software.</p>
<h4>home straight</h4>
<p>The final design phase is to work out the generic <strong>solution for each
UI model</strong>. These will still be toolkit agnostic (not specific for
<acronym>KDE</acronym> or gnome) and, btw, for desktop UI‐only
(touch is a whole ’nother kettle of fish). This will also be specified
in the wiki.</p>
<p>With this, every (typo‐)graphical software project can go to the
wiki, pick a UI model that most matches their own UI structure and see a
concrete UI design that, with a minimum of adaptations, they can
implement in their own application. They will find that HarfBuzz fully supports
their implementation.</p>
<p>While working on Metapolator in the last year I had good experience with
sharing what I was doing almost every day I was working on it, through
<a href="https://plus.google.com/communities/110027004108709154749">its community</a>.
There were encouragement, ideas, discussions, petitions and
corrections—all useful. I think this can be replicated on the
Create list.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-76936826576344632702015-06-11T12:48:00.001+02:002015-06-11T12:52:40.960+02:00a half‑century of success<p><span id="teaser">This is the final instalment of the mini‐series I ran on the usual
social channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>positive action ships successful products</i>. There, for every
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thought</a>
that persists in the (mobile) software industry, I supplied a complementary
positive action.</span></p>
<p>To complete the round number of fifty, I present the final
dozen + two of these for your reference. If you are a product maker, or
manage a product‐shipping organisation, then you can initiate at least
one of these today:</p>
<blockquote id="act1">Make the lead designers of your hard‐ and software
work as a pair; make them inseparable.</blockquote>
<cite><i>cf.</i> ‘The hardware specs are fixed, now we can start with
the software design.’</cite>
<blockquote id="act2">Define your focus so tightly, it hurts (a bit); deploy
it so you ship, instead of discuss.</blockquote>
<cite><i>cf.</i> ‘We spent ages discussing this, trying to find a
solution that pleased everyone.’</cite>
<blockquote id="act3">Make interaction design the backbone of your product
realisation; or compete on low, low price.</blockquote>
<cite><i>cf.</i> ‘We thought we could spend a couple of man‐days on the
low‐hanging usability fruit.’</cite>
<blockquote id="act4">Deploy lightweight design and engineering documentation
to keep everyone with the programme.</blockquote>
<cite><i>cf.</i> ‘The source is the ultimate documentation.’</cite>
<blockquote id="act5">Ban hacks, at least from those who are supposed to shape
your product for the long term.</blockquote>
<cite><i>cf.</i> ‘There is no need to go for the gold‐taps solution.’</cite>
<blockquote id="act6">Set a ‘feature budget’ and set it way below bloat; be frugal, spend it on user value.</blockquote>
<cite><i>cf.</i> ‘It does not hurt to have those features as well.’</cite>
<blockquote id="act7">Set the goal to be competitive on each platform you
support—that starts with your interaction.</blockquote>
<cite><i>cf.</i> ‘One code base; fully cross‐platform.’</cite>
<blockquote id="act8">Root out boilerplate thinking for any product aspect; your design process is your <acronym>QA</acronym>.</blockquote>
<cite><i>cf.</i> ‘You have to pick your battles.’</cite>
<blockquote id="act9">Set up your designers for big impact on the internals of your software, instead of vice versa.</blockquote>
<cite><i>cf.</i> ‘Once you get familiar with the internal workings of
our software, it becomes easy to use.’</cite>
<blockquote id="act10">Define your target user group(s) so tightly, it hurts;
focus on their needs, exclusively.</blockquote>
<cite><i>cf.</i> ‘Our specific target user group is: everyone.’</cite>
<blockquote id="act11">Introduce this <acronym>KPI</acronym>: the more your
developers think the UI is ‘on the wrong track,’
the better.</blockquote>
<cite><i>cf.</i> ‘Our developers are very experienced; they make the UI
of their modules as they see fit.’</cite>
<blockquote id="act12">Hire those who are able to take your interaction beyond
the <acronym>HIG</acronym>, once you achieve compliance.</blockquote>
<cite><i>cf.</i> ‘We religiously adhere
to the <acronym>HIG</acronym>.’</cite>
<blockquote id="act13">Regularly analyse workarounds adopted by your users;
distill from them additional user needs.’</blockquote>
<cite><i>cf.</i> ‘You can do that by [writing, running] a script.’</cite>
<blockquote id="act14">Make the connection: product–users–tech. Design is the process, the solution and realisation.</blockquote>
<cite><i>cf.</i> ‘What do you mean “it’s all
connected”? we just don’t have the time for those bits
and pieces.’</cite>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what else can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>,
or <a href="http://www.xing.com/profile/peter_sikking">xing</a>.</p>
<p>And third, if you <em>able and willing</em> to take some positive action, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will happy to help you ship successful products.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2014/01/12-you-can-do-to-enterprise.html">part three</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-41958890108256416362015-06-04T10:13:00.000+02:002015-06-04T10:13:56.408+02:00designing interaction for creative pros /3<p><span id="teaser">Part three of my
<a href="http://libregraphicsmeeting.org/2015/"><acronym>LGM</acronym> 2015</a>
lecture</span> (here is part
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative.html">one</a> and
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative_12.html">two</a>).
<span id="teaser">It is about <i>equal opportunities</i> in creative‐pro interaction.
To see what I mean, let’s make something: a square.</span></p>
<h3>two‐way street</h3>
<p>There are two ways for masters to get the job done. The first way is to
start somewhere and to keep chipping away at it until
it is right:</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/freesquare.gif"
alt="creating a square by starting with a rectangle, putting it bottom-left
corner into place, then size the top-right one to perfection"
width="380" height="240"/>
<cite>heads up: animated gif</cite>
<p>So let’s throw in some material, move and size it
<em>(<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative_12.html#speed">bam, bam, bam</a>)</em>—right,
done. That was quick and the result is perfect.</p>
<h4>like putty</h4>
<p>This is called free working; squeeze it until it feels right. It is always
<em>hands‑on</em> and I always move both my hands in a moulding motion
when I think of it, to remind me what it feels like.</p>
<p>Although done by feeling, it is still fast and furious. Don’t mistake
this for ‘trying out’, ‘fiddling’ or
‘let’s see where we end up’; that is for dilettantes. When
masters pick up their tools, it is with great confidence that the result they
have in mind will be achieved in a predictable, and short, amount
of time.</p>
<h4>on the other hand…</h4>
<p>The second way for masters to get the job done is to plan a bit and
then create a precise, parametric, set‑up:</p>
<img src="http://mmiworks.net/pics/blog14/jig.png"
alt="top, bottom, left and right guide lines that mark out the perfect square"
width="380" height="240"/>
<p>This is called a <strong>jig</strong>. Now the master only has to
‘cut’ once and a perfect result is achieved:</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/measuredsquare.gif"
alt="top, bottom, left and right guide lines appear one by one, then the
perfect square appears between them" width="380" height="240"/>
<cite>another animated gif</cite>
<h4>measure twice, cut once</h4>
<p>This is called measured working. It is an analytical approach and involves
planning ahead. It delivers precise results, to the limits of the medium.
You will find it in many places; everywhere where the <em>hands‑on</em>
factor is zero, parameters are entered and—<em>bam</em>—the result
is achieved in one stroke.</p>
<p>It might be tempting to think that setting up the jig always involves
punching in numbers. However also making choices from discrete sets, e.g.
picking a color from a set of swatches, is part of it. Thus it is better to
talk in general of entering parameters.</p>
<h3>old‐skool</h3>
<p>I did not make up all this by myself. I am indebted to this very cool
book that goes deep into the matter of free and measured working, as practiced
for centuries by masters. Luckily it is back in print:</p>
<img src="http://mmiworks.net/pics/blog14/workmanship.jpg"
alt="the cover of the book the nature and art of workmanship, by david pye"
width="380" height="546"/>
<p>Once familiar with this duality in how masters work, it can be used to
analyse their workflows. For instance while reading
<a href="http://www.soundonsound.com/sos/sep99/articles/tracks.htm">this article</a>
about Brian Eno working with the band James.</p>
<p>In the sidebar (<i>Eno’s Gear</i>) it says ‘I don’t think
he even saves the sounds that he gets. He just knocks them up from scratch
every time’ about using one piece of gear, and ‘It’s stuffed
full of his own presets’ about another. Reading that, I thought:
that has, respectively, the <em>vibe</em> of free and measured working.</p>
<p>I have looped that insight back into my designs of creative‐pro
software from then on. That is, giving equal importance to users building a
collection of presets and knocking‑it‑up‐from‐scratch
for tool set‑ups, configuring the work environment and assets (brush
shapes, patterns, gradients, et cetera).</p>
<p><i>(There are more nuggets of that’s‐how‐masters‐work in the
<a href="http://www.soundonsound.com/sos/sep99/articles/tracks.htm">Eno article</a>;
see if you can spot them.)</i></p>
<h3>the point</h3>
<p>And with that I have arrived at rule numero one of this blog post:</p>
<blockquote class="solo">All masters work free and measured; the only thing
predictable about it is that it occurs 50–50, with
no patterns.</blockquote>
<p>We <em>cannot</em> rely on a given master taking the same route—free
or measured—for all the different tasks they perform. It’s a mix,
and a different mix for every master. Thus design strategies based on
‘remember if this user tends to do things free or measured’
are flawed.</p>
<p>We <em>cannot</em> rely on a given task being predominantly performed via
either route—free or measured—by masters. It’s a mix, a
50–50 mix. Thus design strategies based on ‘analyse the task; is
it free or measured?’ are flawed.</p>
<h4>same, not same</h4>
<p>The same master doing the same task will pick a different route—free
or measured—at different times, based on the context they are in. For
instance how difficult the overall project is. And for sure their own mood
plays a role; are they under stress, are they tired (that night shift meeting
that deadline)?</p>
<p>Masters will guesstimate the shortest route to success under the
circumstances—and then take it.</p>
<h4>dig it</h4>
<p>With this 50–50 mix and no patterns, software for creative pros has
only one choice:</p>
<blockquote class="solo"><strong>Equal opportunity:</strong> offer every
operation that users can perform in—at least—two ways: one free,
one measured.</blockquote>
<p>If you now say either ‘<em>man</em>, this will double my software in
size’, or ‘yeah, my software already does that’, then my
reply is: experience says that once we really start checking, you will see
that current creative‐pro software achieves 60–80% equal
opportunity.</p>
<h4>how low can you go?</h4>
<p>The question is not how do we prevent this list of operations from
ballooning. It is: are there any more innocent, boring, easy to overlook
operations to go on our list? For instance: setting the document size. Yeah
boring, but often enough key to the creative result. A crop tool is the free
way to do that operation.</p>
<p>From the Brian Eno episode above we have seen that it is not enough to
filter the operations list by ‘does it change the creative end
result?’ There we saw that <em>meta</em>‐operations (set up tools,
configuring the work environment and assets) are also fully in scope.</p>
<h3>picture show</h3>
<p>To illustrate all this, let’s look at some of my designs for
Metapolator.</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/parameterpanel.gif"
alt="the parameters panel listing type parameters on both master and glyph level,
for each parameter values, modifications and effective values are listed.
a popup is used to add a math operator (+) to a parameter (tension)"
width="380" height="390"/>
<cite>a final animated gif</cite>
<p>This is measured central: the parameters panel. <em>Literally</em> here
parameters are entered and—<em>bam</em>—applied. With the popup
action shown the system is taken to the next level. Preferably for
wide‐ranging selections, expressions of change (e.g.
new value = A × old + B) can be built.</p>
<img src="http://mmiworks.net/pics/blog14/handles.jpg"
alt="the curve of the blowl stroke of the b glyph is being edited with use of
some big handles" width="380" height="182"/>
<p>Most on‑canvas interaction is by nature of the free variety. The
hands‑on factor is simply up for grabs. In Metapolator this interaction
complements the parameter panel shown above to achieve equal opportunity.</p>
<img src="http://mmiworks.net/pics/blog14/specimen.jpg"
alt="a specimen is shown with a text generated out of all letter-pair
combinations out of the word adhesion" width="380" height="231"/>
<p>Specimens are a huge factor in the Metapolator design. It is
<strong>the</strong> place to evaluate if the typefaces are <em>right</em>.
That makes it also the logical place to squeeze it until it is right: free
working.</p>
<p>All on‑canvas interaction is performed directly in the specimens for
this reason. If that looks natural and normal to you, I say
‘you’re welcome.’ This is completely novel in the field of
font design software.</p>
<img src="http://mmiworks.net/pics/blog14/4sliders.jpg"
alt="four sliders for mixing fonts, above each slider blue markers, below
each a number equivalent to its setting" width="380" height="183"/>
<p>Here are these fellows
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative_12.html#4sliders">again</a>,
the slider set for freely mixing master fonts to make new fonts. These new
fonts are shown by the blue markers, so that users can <em>feel</em> the
clustering and spread of these new fonts—clearly a component of free
working.</p>
<p>The numbers you see are all editable, also quickly in a row. This supports
measured working. That number input is straightforward and gives predictable
and repeatable results was a big factor for me to choose the algorithm of these
sliders over alternatives.</p>
<h3>boom, boom</h3>
<p><strong>In short:</strong> software for creative pros has to offer every operation
that users can perform in two ways: one free—squeeze it until it feels
right—one measured—involving planning ahead, entering parameters
and ‘cutting’ once.</p>
<p>That’s it for part three. Stay tuned for part four: <i>how to
be good.</i></p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-34919832862459622502015-05-12T19:29:00.000+02:002015-06-11T12:54:39.410+02:00designing interaction for creative pros /2<p><span id="teaser">Part two of my
<a href="http://libregraphicsmeeting.org/2015/"><acronym>LGM</acronym> 2015</a>
lecture</span> (here is
<a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative.html">part one</a>).
<span id="teaser">It is <i>a tale of cars</i>. For many years I have
had these images in my head and used them in my design practice.</span>
Let’s check them out.</p>
<h3>freude am fahren</h3>
<p>First up is the family car:</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/audi100.jpg"
alt="a catalog shot of a family car" width="380" height="235"/>
<cite>source: <a href="http://netcarshow.com/audi/1991-100/">netcarshow.com</a></cite>
<p>It stands for general software. It is comfortable, safe and
general‐purpose. All you need to use it is a minimum of skills,
familiarity and practice—in the case of cars this is covered by
qualifying for a driving licence.</p>
<p>In the case of software, we are talking casual and enthusiast use. A good
example is web browsers. One can start using them with a minimum of skills and
practice. After gaining some experience one can comfortably
<strike>drive</strike> use a browser on a daily basis. If a pro web browser
exists, then it has escaped my radar.</p>
<p><i>(It <em>would</em> make a very interesting project, a pro web browser.
But first a product maker would have to stand up with a solid vision of pro
web browsing; its user groups; and some big innovation that is valuable for
these users.</i></p>
<h3>vroooom</h3>
<p>When I think of creative pro interfaces, I think of this:</p>
<img class="cited" src="http://mmiworks.net/pics/blog14/quatro.jpg"
alt="a rally car blasting around a corner on a rallystage in nature"
width="380" height="285"/>
<cite>source: <a href="http://imgbuddy.com/audi-quattro-rally-wallpaper.asp">imgbuddy.com</a></cite>
<p>The rally car. It is still a car, but… different. It is defined by
performance. And from <em>that</em>, we can learn a couple of things.</p>
<h4 id="speed">speed, baby</h4>
<p>First, creative pros work fast. They ‘wield the knife’ without
doubt. A telltale sign of mastery is the speed of execution. I have this
in mind all the time when designing for creative pros.</p>
<p>I vividly remember one of the earliest <acronym>LGM</acronym>s, <a
href="https://twitter.com/AndyFitz">Andy Fitzsimon</a> went on stage and
demonstrated combining pixel and vector in one image. The pace was impressive,
Andy was performing nearly two operations per second.</p>
<p><strong>Bam bam bam bam</strong>. At a tempo of 120 beats per minute; the
solid tempo of marching bands and disco. That is the rhythm I aim to support,
when designing for creative pros.</p>
<h4>command and control</h4>
<p id="material">Second, creative pros really know their material, the medium
they work with. They can, and need to, work with this material as direct and
intimate as possible, in order to fulfil creative or commecial goals. This all
can be technology‐assisted, as it is with software, but the technology
has to stay out of the way, so that it does not break the bond between master
and material.</p>
<p>The material I am talking about is that of film, graphics, music,
animation, garments, et cetera. These can be digital, yes. However data and
code of the software‐in‐use are not part of a creative pro’s
material. Developers are always shocked, angry, then sad to
learn this.</p>
<p>Thus <a href="http://blog.mmiworks.net/search/label/metapolator">Metapolator</a>,
has been designed for font designers and typographers who know what makes a
font and what makes it tick. They know the role of the strokes, curves,
points, the black and the white, and of the spacing. They are experienced in
shaping these to get results. It is this material that—by
design—Metapolator users access, just that it is organised such that
they can work ten times faster.</p>
<h4>dog eat dog</h4>
<p>Third, it’s a competitive world. Creatives pros are not just in
business. Also in zero‐budget circles there are real fun and/or
prestigious projects where exactly those with proven creative performance, and
ability to deliver, get asked.</p>
<p>Tools and software are in constant competition, also in the world of
<acronym>F/LOSS</acronym>. It is a constant tussle: which ones provide
<em>next</em>‐generation workflows with more speed and/or more room for
creativity? Only competitive tools make masters competitive.</p>
<h3>the point</h3>
<p>Now that we got the picture, here is the conflict. The rules—the law
and industry mores—that make good family cars <em>may</em> be a bad idea
to apply to rally cars. And what makes rally cars competitive, <em>may</em>
simply be illegal for family cars.</p>
<p>Every serious software platform has its <acronym>HIG</acronym> (human
interface guidelines). It is the law, a spiritual guide and a huge source of
security for developers. That is, for general software. It is only partly
authoritative for software for creative pros. Because truly sticking to the
<acronym>HIG</acronym>, while done all in good faith, will render creative pro
software non‐competitive.</p>
<h4>vorsprung durch technik</h4>
<p>Rally cars contain custom parts, handmade from high performance materials
like aluminium, titanium, carbon, etc. This is expensive and done because
nothing off‐the‐shelf is sufficient.</p>
<p>Similarly creative pro software contains custom widgets, handmade at great
expense—in design and development. For a decade I have witnessed that it
is a force of nature to end up in that situation. Not for the sake of being cool
or different, but all in the name of performance.</p>
<h4>tough cookie</h4>
<p>So, with loose laws and a natural tendency for custom widgets, can you do
just what you like when you make creative pro software? Well no. <strong>It is
tough, you still have to do the right thing.</strong> If this situation makes
you feel rather lost, without guidance, then reach out and find yourself an
interaction designer who really knows <em>this type</em> of <a
href="material">material</a>. Make them your compass.</p>
<h3>picture show</h3>
<p>To illustrate all this, let’s look at some of my designs for
Metapolator.</p>
<img src="http://mmiworks.net/pics/blog14/bighandles.jpg"
alt="of a glyph—surrounded by two others—all the points that make up its
skeleton are connected by outward radiating lines to big circular handles"
width="380" height="277"/>
<p>Speed, baby! Big handles to select and move individual points on the
skeleton of a glyph <i>(i.e. direct control of the material)</i>. During a
brainstorm session with Metapolator product visionary Simon Egli, he noticed
how the points could be connected by <em>rigid sticks</em> to
big handles.</p>
<p>I worked out the design with big (fast) handles available for furious
working, but out of the way of the glyph, so it can be continuously evaluated
<i>(unbroken workflow)</i>.</p>
<img id="4sliders" src="http://mmiworks.net/pics/blog14/4sliders.jpg"
alt="four sliders for mixing fonts, one is reversed and has its thumb aligned
with another slider" width="380" height="183"/>
<p>This is a custom slider set for freely mixing master
fonts—metapolation—to make new fonts. In this case four fonts, but
it has been designed to easily scale up to nine or more; a Metapolator
strength <i>(vis‑à‐vis the competition)</i>.</p>
<p>One of the sliders—‘Alternate’—is in an
“illegal” configuration; it is reversed. This is done to implement
the rule that the mix of fonts has to always add up to 100%. There is special
coupled behaviour between the sliders to ensure that.</p>
<p>The design of this part included a generous amount of
<a href="https://github.com/metapolator/metapolator/wiki/metapolation">exploration</a>
and several major revisions. Standard widgets and following the
<acronym>HIG</acronym> would not deliver that every sliders setting
maps to one unique font mix. Apart from a consistency goal, that is also about
maximising input resolution. So I broke some rules and went custom.</p>
<img src="http://mmiworks.net/pics/blog14/3Dcross.jpg"
alt="a crossing 2-D axies system coupled to a single axis, with at least
3 fonts on each axis, with a font family and a single font instance placed
on them" width="380" height="390"/>
<p>This is also a metapolation control. In this case a three‐dimensional
one involving eight master fonts. Working with that many fonts is really a pro
thing; you have to know what you are doing and have the experience
to set up, identify and pick the ‘good font’ results.</p>
<p>The long blue arrow is a font family, with nine or so fonts as members. The
whole family can be manipulated as one entity (i.e. placed and spanned in this
<acronym>3</acronym>‑<acronym>D</acronym> space) as can each member
font individually.</p>
<img src="http://mmiworks.net/pics/blog14/3x3selected.jpg"
alt="glyphs a, b and c set in 3 different fonts, with point selections across them"
width="380" height="190"/>
<p>Final example: complex selections. Across three different fonts and three
different glyphs, several points have been selected. Now they can be
manipulated at the same time. That is definitely not consumer‑grade.</p>
<p>If that looks easy, I say ‘you’re welcome.’ It takes
serious planning ahead in the design to allow this interaction; for the three
fonts to appear, editable, at the same time; for deep selections within
several glyphs to be possible and manageable—the big
handles‑on‐sticks help also here.</p>
<h3>vroom, vroom</h3>
<p><strong>In short:</strong> if there is one thing that I want you to take
away from this blog post, then it is that image of the rally car. How
different its construction, deployment and handling are. Making software for
creative pros means making a product that is definitely not
consumer‑grade.</p>
<p>That’s it for part two. Go straight to part three: <a href="http://blog.mmiworks.net/2015/06/designing-interaction-for-creative.html">50–50,
equal opportunities</a>.</p>Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com2tag:blogger.com,1999:blog-28919981.post-88544488297038165362015-05-07T19:23:00.000+02:002015-06-11T12:54:39.424+02:00designing interaction for creative pros /1 <p><span id="teaser">Last week at
<a href="http://libregraphicsmeeting.org/2015/"><acronym>LGM</acronym> 2015</a>
I did a lecture on one of my fields of specialisation:
designing interaction for creatives. There were four sections and
I will cover each of them in a separate blog post. Here is part one.</span></p>
<p>The lecture coincided with the launch of <a href="https://metapolator.com/purple-pill/">the demo</a> of
<a href="http://blog.mmiworks.net/search/label/metapolator">Metapolator</a>,
a project I have been working on since <acronym>LGM</acronym> 2014. All the
practical examples will be from that project and my
designs for it.</p>
<h3>see what I mean?</h3>
<p class="hang">‘So what’s Metapolator?’ you might ask.
Well, there is a definition for that:</p>
<p class="hang">‘Metapolator is an open web tool for making many fonts.
It supports working in a font design space, instead of one glyph, one face,
at a time.</p>
<p class="hang">‘With Metapolator, “pro” font designers are
able to create and edit fonts and font families much faster, with inherent
consistency. They gain unique exploration possibilities and the tools to
quickly adapt typefaces to different media and domains of use.</p>
<p class="hang">‘With Metapolator, typographers gain the possibility to
change existing fonts—or even create new ones—to
their needs.</p>
<p class="hang">‘Metapolator is extendible through plugins and custom
specimens. It contains all the tools and fine control that designers need to
finish a font.’</p>
<h4>theme time</h4>
<p>That is the
<a href="http://blog.mmiworks.net/search/label/product%20vision">product vision</a>
of Metapolator, which I helped to define the moment I got involved with the
project. You can read all about that in
<a href="http://blog.mmiworks.net/2014/04/writing-product-vision-for-metapolator.html">the making‑of</a>.</p>
<p>One of the key questions answered in a product vision is: <em>who is this for?</em>
And with that, I have arrived at what this blog post is about:</p>
<blockquote class="solo">Products need a clear, narrow definition of their
target users groups. Software for creatives needs a clear definition
whether it is for professionals, or not.</blockquote>
<p>Checking the vision, we see that Metapolator user groups are well defined.
They are ‘“pro” font designers’ and
‘typographers.’ The former are pro by definition and the latter
come with their own full set of baggage; they are pro by implication.</p>
<h4>define it like a pro</h4>
<p>But what does pro actually mean? And why is it in quotes in the Metapolator
vision? Well, the rather down‐to‐earth definition of
professional—earning money with an occupation—is not helping us
here. There are many making‐the‐rent professionals who are
terrible hacks at what they do.</p>
<p>Instead it is useful to think of pros as <em>those who have mastered a
craft</em>—a creative craft in our case. Examples of these are drawing,
painting; photographing, filming, writing, animating, and editing these;
sewing, the list goes on and on.</p>
<p>Making software for creative pros means making it for those who have
<em>worked</em> at least 10.000 hours in that field, honing their craft. And
also making it for for the apprentices and journeymen who are working to get
there. These two groups do not need special ‘training wheels’
modes; they just need to get their hands dirty with
the real thing.</p>
<h3>the point</h3>
<p>The real world just called and left a message:</p>
<blockquote class="solo">making it for pros comes
at a price.</blockquote>
<p>First of all, it is very demanding—I will cover this in the
follow‑up posts. Second, it puts some real limits on <em>who
else</em> you can make it for. Making it for…</p>
<dl>
<dt>pros</dt>
<dd>is perfectly focussed, to meet those demanding needs.</dd>
<dt>pros + enthusiasts</dt>
<dd>(the latter also known as prosumers.) This compromises how good one can make
it for pros; better keep in check how sprawling that enthusiast faction is
allowed to be.</dd>
<dt><strike>pros + enthusiasts + casual users</strike></dt>
<dd>forget it, because pros and casual have diametrically opposite needs.
There is no <em>room</em> in the UI for both, and with room I mean screen real
estate and communication bandwidth.</dd>
<dt><strike>pros + casual users</strike></dt>
<dd>for the same reasons one can royally forget about this one too.
Enough said.</dd>
</dl>
<h4>the fall‐out</h4>
<p>You might think: ‘duh, that speaks for itself, just make the right
choice and roll with it.’ If it was only that easy. My experience has
been that projects <em>really</em> do not like to commit here, especially when
they know the consequences outlined above. And when they did make a choice,
I have seen the natural tendency to worm out of it later.</p>
<p>I guess that having clear goals is scary for quite a few folks. Having
focussed user groups means saying ‘we don’t care about you’
to vast groups of people. Only the visionary think of that as positive.</p>
<p>Furthermore, clear goals are a fast and effective tool to weed out bad
ideas, on an industrial scale. That’s good for the product, but upsets
the people who came up with these ideas. So they renegotiate on the clear
goals, attacking the root of the rejection.</p>
<h4>no fudging!</h4>
<p><strong>In short:</strong> define it; is your software for creatives made
for pros, or not? Then compile a set of coherent user groups. In the case of
Metapolator the ‘pro’ font designers and typographers fit together
beautifully. Once defined, stick with it.</p>
<p>That’s it for part one. Here is part two: <a href="http://blog.mmiworks.net/2015/05/designing-interaction-for-creative_12.html">a
tale of cars.</a></p>
<p class="double"><i>[editor’s note: Gee Peter, this post contains
a lot of talk about pros, but where is the creative angle?]</i>
True, the gist this post is valid for all professionals.
The upcoming parts will feature more ‘creative’ content,
more Metapolator, and illustrations.</p>Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-45215844101312007522014-04-25T22:01:00.000+02:002015-06-11T12:54:39.415+02:00writing a product vision for Metapolator <p><span id="teaser">A week ago I kicked off my involvement with the
<a href="http://metapolator.com/">Metapolator</a> project as I always do:
with a product vision session.</span> Metapolator is an
<a jref="https://plus.google.com/communities/110027004108709154749/">open project</a>
<em>and</em> it was the first time I did the session online, so you have the chance to see the
<a href="https://plus.google.com/events/cmq6h9j3m858vtgq9rhf4gu8pok">session recording</a>
(warning: 2½ hours long), which is a
<a href="https://plus.google.com/+JakubSteiner/posts/Zvaw1Hr3c3b">rare opportunity</a>
to witness such a highly strategic meeting; normally this is top‐secret stuff.</p>
<h3>boom boom</h3>
<p>For those not familiar with a
<a href="http://blog.mmiworks.net/search/label/product%20vision">product vision</a>,
it is a statement that <a href="http://mmiworks.net/wedo/product.html">we define</a>
as ‘the heartbeat of your product, it is what you are making, reduced down
to its core essence.’ A clear vision helps a project to focus, to fight off
distractions and to take tough design decisions.</p>
<p>To get a vision on the table I moderate a session with the people who
<em>drive</em> the product development, who I simply ask ‘what is it
we are making, who is it for, and where is the value?’ The session lasts
until I am satisfied with the answers. I then write up the vision
statement in a few short paragraphs and fine-tune it with the session
participants.</p>
<p>To cut to the chase, here is the product vision statement for Metapolator:</p>
<blockquote class="hang">‘Metapolator is an open web tool for
making many fonts. It supports working in a font design space, instead of one
glyph, one face, at a time.</blockquote>
<blockquote class="hang">‘With Metapolator, “pro” font
designers are able to create and edit fonts and font families much faster,
with inherent consistency. They gain unique exploration possibilities and the
tools to quickly adapt typefaces to different media and domains of use.</blockquote>
<blockquote class="hang">‘With Metapolator, typographers gain the
possibility to change existing fonts—or even create new ones—to
their needs.</blockquote>
<blockquote class="hang">‘Metapolator is extendible through plugins
and custom specimens. It contains all the tools and fine control that
designers need to finish a font.’</blockquote>
<h3>mass deconstruction</h3>
<p>I think that makes it already quite clear what Metapolator is. However, to
demonstrate what goes into writing a product vision, and to serve as a more
fleshed out <em>vision briefing</em>, I will now discuss it sentence
by sentence.</p>
<blockquote class="hang">‘Metapolator is an open web tool for
making many fonts.’</blockquote>
<ul>
<li>There is no standard template for writing a product vision, the structure
it needs is as varied as the projects I work with. But then again it has
always worked for me to lead off with a statement of
<strong>identity</strong>; to start answering the question ‘what is it
we are making?’ And here we have it.</li>
<li><strong>open</strong> or libre? This was discussed during the session. At
the end <a href="https://plus.google.com/100858309774292261525/posts">Simon Egli</a>,
Metapolator founder and driving force, wanted to express that we aim beyond
just libre (i.e. open source code) and that ‘open’ also
applies to the vibe of the tool on the user side.</li>
<li><strong>web</strong>‑based: this is not just a statement of the
technology used, of the fact that it runs in the browser. It is also a solid
commitment that it runs on all desktops—mac, win and linux. And it
implies that starting to use Metapolator is as easy as clicking/typing the
right <acronym>URL</acronym>; nothing more required.</li>
<li><strong>tool</strong> or application? The former fits better with the
fact that font design and typography are master crafts (I can just
<em>see</em> the tool in the hand of the master).</li>
<li><strong>making</strong> or designing fonts? I have learned in the last
couple of weeks that there is a font design phase where a designer
concentrates on shaping eight strategic characters (for latin fonts). This is
followed by a production phase where the whole character set is fleshed out,
the spacing between all character pairs set, then different weights (e.g. thin
and bold) are derived and maybe also narrow end extended variants. This
phase is very laborious and often outsourced.
‘Making’ fonts captures both design and production phases.</li>
<li><strong>many fonts</strong>: this is the heart of the matter. You can see
from the previous point that making fonts is up to now a piecemeal activity.
Metapolator is going to change that. It is dedicated to either making many
different fonts in a row, or a large font family, even a collection of
related families. The implication is that in the user interaction of
Metapolator the focus is on making many fonts and the user <em>needs</em> for
making many fonts take precedence in all design decisions.</li>
</ul>
<blockquote class="hang">‘It supports working in a font design
space, instead of one glyph, one face, at a time.’</blockquote>
<ul>
<li>The first sentence said that Metapolator is going to change the world—by
introducing a tool for making many fonts, something not seen before; this second
one tells us <strong>how</strong>.</li>
<li><strong>supports</strong> is not a word one uses lightly in a vision.
‘Supports <i><acronym>XYZ</acronym></i>’ does not mean it is just
technically possible to do <i><acronym>XYZ</acronym></i>; it means here that
this is going to be a world‐class product to do
<i><acronym>XYZ</acronym></i>, which can only be realised with
world‐class user interaction
to do <i><acronym>XYZ</acronym></i>.</li>
<li><strong>design space</strong> is one of these wonderful things that come
up in a product vision session. Super‐user Wei Huang coined the phrase
when describing working with the current version of Metapolator. It captures
very nicely the working in a continuum that Metapolator supports, as
contrasted with the traditional piecemeal approach, represented by ‘one
glyph, one face, at a time.’ What is great for a vision is that
‘design space’ captures the vibe that working with metapolator
should have, but that it is not explicit on the realisation of it. This means
there is room for innovation, through technological <acronym>R&D</acronym> and
interaction design.</li>
</ul>
<blockquote class="hang">‘With Metapolator, “pro” font
designers are able to create and edit fonts and font families much faster,
with inherent consistency.’</blockquote>
<ul>
<li>With <strong>“pro” font designers</strong> we encounter the
first user group, starting to answer ‘who is it for?’
“Pro” is in quotes because it is not the
earning‑a‐living part that interests us, it is the fact that these
people mastered a craft.</li>
<li><strong>create and edit</strong> balances the two activities; it is not all about
creating from scratch.</li>
<li><strong>fonts and font families</strong> balances making very different fonts
with making families; it is not all about the latter.</li>
<li><strong>much faster</strong> is the first value statement, starting to
answer ‘where is the value?’ Metapolator stands for an impressive
speed increase in font design and production, by abolishing the piecemeal
approach.</li>
<li><strong>inherent consistency</strong> is the second value statement.
Because the work is performed by users in the font design space, where
everything is connected and continuous, the conventional user overhead of
keeping everything consistent disappears.</li>
</ul>
<blockquote class="hang">‘They gain unique exploration
possibilities and the tools to quickly adapt typefaces to different media and
domains of use.’</blockquote>
<ul>
<li><strong>exploration possibilities</strong> is part feature, part value
statement, part field of use and part vibe. All these four are
completely different things (e.g. there is inherently zero value in a feature),
captured in two words.</li>
<li><strong>quickly adapt</strong> is a continuation of the ‘much faster’
value statement above, highlighting complementary fields of use for it.</li>
</ul>
<blockquote class="hang">‘With Metapolator, typographers gain the
possibility to change existing fonts—or even create new ones—to
their needs.’</blockquote>
<ul>
<li>And with <strong>typographers</strong> we encounter the second user group.
These are people who use fonts, with a whole set of typographical skills and
expertise implied.</li>
<li><strong>possibility to change</strong> is the value statement for this
user group. This is a huge deal. Normally typographers have neither the skills,
nor the time, to modify a font. Metapolator will open up this world to them,
with that fast speed and inherent consistency that was mentioned before.</li>
<li><strong>create new</strong> goes one step further than the previous point.
Here we have now a commitment to enable more ambitious typographers
(that is what ‘even’ stands for) to create new fonts.</li>
<li><strong>to their needs</strong> is a context we should be aware of.
These typographers will be designing something, anything with text, and that
is their main goal. Changing or creating a font is for them a worthwhile
way to get it done. But it is only part of their job, not <em>the</em> job.
Note that the needs of typographers includes applying some
very heavy graphical treatments to fonts.</li>
</ul>
<blockquote class="hang">‘Metapolator is extendible through plugins
and custom specimens.’</blockquote>
<ul>
<li><strong>extendible through plugins</strong> is one realisation of the
‘open’ aspect mentioned in the first sentence. This makes
Metapolator a platform and its extendability will have to be taken into account
in every step of its design.</li>
<li><strong>custom specimens</strong> is slightly borderline to mention in a
vision; you could say it is just a feature. I included it because it
programs the project to properly <em>support</em> working with type
specimens.</li>
</ul>
<blockquote class="hang">‘It contains all the tools and fine control that
designers need to finish a font.’</blockquote>
<ul>
<li><strong>all the tools</strong>: this was the result of me probing during
the vision session whether Metapolator is thought to be part of a tool chain, or
independent. This means that it must be designed to work
stand‑alone.</li>
<li><strong>fine control</strong>: again the result of probing, this time
whether Metapolator includes the finesse to take care of those important
details, on a glyph level. Yes, it all needs to be there.</li>
<li><strong>that designers need</strong> makes it clear by whose
standards the tools and control needs to be made: that of the two user groups.</li>
</ul>
<h3>this space has intentionally been left blank</h3>
<p>Just as important as what it says in a product vision is what it
doesn’t say. What it does not say Metapolator is, Metapolator is
explicitly not. Not a vector drawing application, not a type layout program,
not a system font manager, not a tablet or smartphone app.</p>
<p>The list goes on and on, and I am sure some users will come up with highly
creative fields of use. That is up to them, maybe it works out or they are
able to cover their needs with a plugin they write, or have written for them.
For the Metapolator team that is charming to hear, but definitely out of scope.</p>
<p>User groups that are not mentioned, i.e. everybody who is not a
“pro” font designer or a typographer, are welcome to check out
Metapolator, it is free software. If their needs overlap partly with that of
the defined user groups, then Metapolator will work out partly for them. But
the needs of all these users are of no concern to the Metapolator team.</p>
<p>If that sounds harsh, then remember what a product vision is for: it helps
a project to focus, to fight off distractions and to take tough design
decisions. That part starts now.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-44885246893044748612014-03-18T10:50:00.000+01:002014-03-18T11:08:20.180+01:00a Maslow hierarchy of software making <p><span id="teaser">This morning, I whipped up a
<a href="http://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs">Maslow hierarchy</a>
for breakfast, one for the activity of software making</span>:</p>
<img src="http://mmiworks.net/pics/blog14/Maslow.png"
alt="the Maslow hierarchy of software making" width="380" height="450"/>
<p><span id="teaser">My thoughts started where one normally starts explaining
the hierarchy: at the bottom.</span> I recalled what I wrote here
<a href="http://blog.mmiworks.net/2013/04/collisions-in-software-projects-and.html">a while ago</a>:</p>
<blockquote class="hang solo">‘<em>Everyone</em> knows that in order to get
software, it needs to get built, i.e. code developed.’</blockquote>
<p>And with that I had my first, ‘physiological’ level of software
making: to <strong>build</strong>. Without it, there is nothing. This is the
hammer and saw level; just cut it to size and nail it together.</p>
<p>You would be surprised how much software is made like this—yes, also
for top dollar.</p>
<h3>moving on up</h3>
<p>The next level is to <strong>engineer</strong>. At this point one is not
just cobbling code together, there is also thought and structure involved, on
a technological level. This is all about avoiding chaos, being able to scale
up—in size and complexity—and code being maintainable in
the future.</p>
<p>We can use these two levels to illustrate a common source of strife in
software development outsourcing. The customer thinks they will get an
engineered solution for their money; the supplier thinks they can just
<em>build</em> whatever passes the acceptance tests.</p>
<p>Maslow’s second level is called <em>safety</em>. Somehow that
matches quite well with what software engineering is about.</p>
<h4>a giant leap</h4>
<p>One level up is a whole new ballgame: to <strong>plan features</strong>.
This requires having a
<a href="http://www.mmiworks.net/wedo/product.html">product vision</a> and
picking only those features that make the product stronger, while saying
‘no’ to 95% of the features that users, marketing and
engineering come up with.</p>
<p>This is the entry level for putting some purpose into the activity; to make
software that matters. It is not easy to make it up to here; respect for those
who do. It takes a visionary person, confident enough to deal firmly but
correctly with all the wild impulses that come from users and engineering.</p>
<p>The corresponding Maslow level is called <em>love</em>. Indeed, to plan
features is the first step of putting some love into the software you
are making.</p>
<h4>accident prune</h4>
<p>The fourth level is to take the random factor out of software making: to
<strong>specify</strong>. Define first <em>what</em> needs to be made, before
engineering figures out <em>how</em> it can be built. This roots out the
standard practice of the <em>how</em> determining <em>what</em> the
result will be.</p>
<p>I am totally not a fan of heavyweight, bureaucratic specifications. Just
keep in mind: the point <em>is</em> that a project should be able to tip the
code, swap out the complete engineering crew and be confident to resurrect
exactly the same software from spec—just with different bugs.</p>
<h3>full potential</h3>
<p>And now we reach the top, the level of complete product realisation: to
<strong>design</strong>. The focus moves to product <em>value</em> delivery, by
addressing user <em>needs</em>, while taking into account what is
<em>feasible</em> with technology.</p>
<p>A software project that is operating smoothly on all five levels of the
hierarchy is one that is delivering its full potential. It can concentrate on
realising its vision and through that be a leader in its market.</p>
<p>Conversely, a project where one or more levels of the hierarchy are
missing, or not functioning well, will spend a considerable amount of its
energy on trying to fill the void(s). The organisation may not <em>quite</em >
be able to put its finger on what is wrong, but spend a lot of communication,
meetings, time and action on correcting it.</p>
<p>Maslow’s top level is
<a href="http://en.wikipedia.org/wiki/Maslow's_hierarchy_of_needs">summed up as</a>—</p>
<blockquote class="hang solo">‘morality, creativity, spontaneity,
problem solving, lack of prejudice and acceptance of facts’</blockquote>
<p>That’s a pretty good trait‐requirements list for a designer. Stated
the other way around, to design <em>is</em> a human need of the
highest level.</p>
<h4>use it</h4>
<p>Now we can work the diagram, in true Maslow style:</p>
<blockquote class="solo">An organisation will only be motivated to fix the
lowest level that is found lacking.</blockquote>
<p>As we have already seen, the <i>build</i> level trumps anything. Problems
on this level—e.g. lack of developers, or ‘physiological’
bugs (crashing)—will crowd out any other considerations. Moving up, if
the engineering is found lacking, then an organisation will not be inclined to
take feature‐planning, specification, or design serious.</p>
<p>If an organisation fails to plan features then design and/or specification
initiatives will be in vain. Is the specification process found lacking? Then
it will be hard for an organisation to become design‑driven.</p>
<p>Working the diagram, we can understand how software‐making
organisations act.</p>
<h4>postscript</h4>
<p>Here is something I noticed when I looked at the hierarchy diagram: it
doesn’t mention software or anything related, does it?</p>
<p>Turns out the diagram is general for any design discipline; it is a Maslow
hierarchy of making <em>anything</em>.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-14483076753953283092014-01-30T11:54:00.000+01:002015-06-11T12:54:39.396+02:0012 things you can do to succeed, enterprise edition <p>Part three of the mini‐series I am running at the moment on the usual
social channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>positive action ships successful products</i>. There, for every
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thought</a>
that persists in the (mobile) software industry, I supply a complementary
positive action.</p>
<p><span id="teaser">Today’s offering is enterprise grade; let’s
turn water into wine. If you are a product maker, or manage a
product‐shipping organisation, then you can initiate at least one of
these today</span>:</p>
<blockquote id="act1">Better go for it, deploy user research and design to
ensure that <em>new</em> is really better.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, because it has not been
done before.’</cite>
<blockquote id="act2">Better go for it, ban meetings; get the makers to
collaborate in (pairs of) pairs.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, so it won’t cause all these
extra rounds of meetings.’</cite>
<blockquote id="act3">Better go for it, evangelise the new, listen carefully
to any needs, ignore naysayers.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, because the first feedback was
rather reserved.’</cite>
<blockquote id="act4">Better go for it, make it an offer that can’t be
refused—if it gets nixed, go underground.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, so we
get the <acronym>OK</acronym>.’</cite>
<blockquote id="act5">Better go for it, negotiate until you trust that the
engineers can build the design.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, because the engineers say it
cannot be done.’</cite>
<blockquote id="act6">Better go for it, it is faster to build a completely new
core product from scratch.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, because that code base is spaghetti.’</cite>
<blockquote id="act7">Better go for it, and enjoy every minute; save time
through structure, research + design.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, so we all can go home at
five—and on 14:30 (<acronym>D</acronym>) / to the pub
(<acronym>GB</acronym>) on friday.’</cite>
<blockquote id="act8">Better go for it, because the blame will fall on us anyway.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, because the blame will
fall on us.’</cite>
<blockquote id="act9">Better go for it, once the core product blows away the
competition, features can be added.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, so we have time for more features.’</cite>
<blockquote id="act10">Better go for it, use frequent user testing to debug
the innovative design.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, to pass the usability test.’</cite>
<blockquote id="act11">Better go for it, define a new game, on your terms, and
ditch them old millstones.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, to pass the regression test.’</cite>
<blockquote id="act12">Better go for it, model careers are built on delivering remarkable results.</blockquote>
<cite><i>cf.</i> ‘Better play it safe, to not jeopardise my promotion.’</cite>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what else can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh jolt of positive action every workday.</p>
<p>And third, if you <em>able and willing</em> to take some positive action, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will happy to help you ship successful products.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2014/01/another-12-you-can-do-to.html">part two</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-23748903105483521572014-01-09T19:08:00.001+01:002014-01-30T11:54:22.649+01:00another 12 things you can do to succeed <p><span id="teaser">Part two of the mini‐series I am running at the
moment on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>positive action ships successful products</i>. There, for every
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thought</a>
that persists in the (mobile) software industry, I supply a complementary
positive action.</span></p>
<p>Below I list the second dozen pairs of these for your reference. If you are
a product maker, or manage a product‐shipping organisation, then you can
initiate at least one of these today:</p>
<blockquote id="act1">Identify the different nature/vibe of your product
modules and flows; design them accordingly.</blockquote>
<cite><i>cf.</i> ‘A list is a list is a list. Why do these two parts of
our app need such a different design?’</cite>
<blockquote id="act2">Hire a (lead) designer whose career is longer than that
of your most senior developer
(and the <acronym>CTO</acronym>).</blockquote>
<cite><i>cf.</i> ‘Sure, it needs to be designed. Let’s get a
[student, intern] for that.’</cite>
<blockquote id="act3">Tackle usability from the core outwards: how your
product works; stop tinkering on the fringes.</blockquote>
<cite><i>cf.</i> ‘Our usability sucks. To fix that, maybe we can take
some guidelines and apply them religiously.’</cite>
<blockquote id="act4">Erect a chinese wall between your product and the
customer wishes you are forced/paid to build.</blockquote>
<cite><i>cf.</i> ‘The features our most‐valued customers ask for
are implemented asap, future plans be damned.’</cite>
<blockquote id="act5">Start your development cycle by structuring it with your
designer(s); serious work starts then.</blockquote>
<cite><i>cf.</i> ‘The development is almost finished, now we need some
design on top to jazz it up.’</cite>
<blockquote id="act6">Celebrate that your organisation is an exclusive group
of insiders; real users are out there.</blockquote>
<cite><i>cf.</i> ‘We are the typical users.’</cite>
<blockquote id="act7">Plan with a single, integral solution from your
designer(s), which gets continuously refined.</blockquote>
<cite><i>cf.</i> ‘Let’s get the designer(s) to deliver 3
proposals, then we pick—and mix—what we like.’</cite>
<blockquote id="act8">Refuse to get your data separated from the value your
product delivers.</blockquote>
<cite><i>cf.</i> ‘For that you can export the data to excel.’</cite>
<blockquote id="act9">Hire user researchers to map out how your core users
tick and what their needs are.</blockquote>
<cite><i>cf.</i> ‘We did do user research; we asked them what they liked
and not, and what was missing.’</cite>
<blockquote id="act10">Fight rust; regularly identify product areas that were
stable for years and redesigned them.</blockquote>
<cite><i>cf.</i> ‘We have been doing it like this for many years.’</cite>
<blockquote id="act11">Stamp out the tinkering; get it designed,
completely—no holes; documented nimbly,
‘on paper.’</blockquote>
<cite><i>cf.</i> ‘We design in code.’</cite>
<blockquote id="act12">Hog effort, your organisation deals with it; your users
get to do their thing, effortlessly.</blockquote>
<cite><i>cf.</i> ‘Really, users could also put some effort into using
our software.’</cite>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what else can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh jolt of positive action every workday.</p>
<p>And third, if you <em>able and willing</em> to take some positive action, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will happy to help you ship successful products.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2013/12/12-you-can-do-to.html">part one</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-28565173638727740642013-12-18T09:50:00.000+01:002014-01-09T19:09:24.602+01:0012 things you can do to succeed <p class="hang">‘Stop the wishful thinking and get on with some positive
action.’ That is what I was thinking when I wrapped up the
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">mini‐series</a>
<i>wishful thinking breeds failed products</i> on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>
and <a href="http://www.xing.com/profile/peter_sikking">xing</a>.</p>
<p><span id="teaser">Thus I kicked off a new series: for every wishful thought, I devised a
complementary <i>positive action</i> that <i>ships successful products</i>.</span>
Below I list the first dozen pairs of these for your reference. If you are a product
maker, or manage a product‐shipping organisation, then you can
initiate at least one of these today:</p>
<blockquote id="act1">Drive your market, beyond your customers’ wildest
dreams; stamp out any reactive thinking.</blockquote>
<cite><i>cf.</i> ‘Just ask the customers, they know best.’</cite>
<blockquote id="act2">Establish technology selection processes where the
driver is user value delivery.</blockquote>
<cite><i>cf.</i> ‘Users will love our hot, new technology, they will be
queuing around the block.’</cite>
<blockquote id="act3">Institutionalise <acronym>QA</acronym> beyond
bugs—of design; its execution; usability; of your
communication.</blockquote>
<cite><i>cf.</i> ‘With zero (major) bugs in the tracker, this feature
must be working well.’</cite>
<blockquote id="act4">Improve your product—just because you know it can
be done better: design it, test it, ship it.</blockquote>
<cite><i>cf.</i> ‘But why? nobody ever complained about that.’</cite>
<blockquote id="act5">Pick the right defaults for your product; let users
configure it by ‘just putting it right.’</blockquote>
<cite><i>cf.</i> ‘We’ll leave that choice to our users, via a
setting in the preferences.’</cite>
<blockquote id="act6">Get the usability right early on, then follow through on
the design details to the very end.</blockquote>
<cite><i>cf.</i> ‘In this phase of development, usability is a
nice‐to‑have.’</cite>
<blockquote id="act7">Establish a design department, working at
eye‑level with product management and engineering.</blockquote>
<cite><i>cf.</i> ‘Our product designers are part of the [marketing,
engineering, product, operations] department.’</cite>
<blockquote id="act8">Improve the status quo—because you know it can be
done better: design it, test it, ship it.</blockquote>
<cite><i>cf.</i> ‘This is what users are used to; we better not
change it.’</cite>
<blockquote id="act9">Stamp out any notion that making your product is somehow
directly related to using it.</blockquote>
<cite><i>cf.</i> ‘We started out by scratching our itch; today, we still
make it exactly how we like it.’</cite>
<blockquote id="act10">Consistently feed qualitative data into your design
process; leave numbers to bookkeepers.</blockquote>
<cite><i>cf.</i> ‘With all this quantitative tracking data, we know
exactly what works, and what not.’</cite>
<blockquote id="act11">Plan every version—major and dot—around
increased user value; the rest follows from that.</blockquote>
<cite><i>cf.</i> ‘For our next version, we will refactor a lot of the
code; a huge effort, so no other changes.’</cite>
<blockquote id="act12">It is your market, you design what is right for
it—in an ever‐changing world.</blockquote>
<cite><i>cf.</i> ‘I can’t see why we would do it differently from how [facebook, microsoft, google, adobe] do it.’</cite>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh jolt of positive action every workday.</p>
<p>And third, if you <em>able and willing</em> to take some positive action, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will happy to help you ship successful products.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-73968332425313055602013-11-16T13:26:00.000+01:002015-06-05T20:28:45.992+02:00a half‑century of product fail <p><span id="teaser">This is the final instalment of the
mini‐series I ran on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>wishful thinking breeds failed products</i>. It distilled what I have
witnessed and heard during 20 years in the (mobile) software industry.</span></p>
<p>To complete the round number of fifty, I present
the final dozen + two wishful thoughts for future reference.
I am curious if you recognise some of these:</p>
<blockquote id="wish1" class="hang">‘The hardware specs are fixed, now
we can start with the software design.’</blockquote>
<blockquote id="wish2" class="hang">‘We spent ages discussing this,
trying to find a solution that pleased everyone.’</blockquote>
<blockquote id="wish3" class="hang">‘We thought we could spend a couple
of man‐days on the low‐hanging usability fruit.’</blockquote>
<blockquote id="wish4" class="hang">‘The source is the ultimate
documentation.’</blockquote>
<blockquote id="wish5" class="hang">‘There is no need to go for the
gold‐taps solution.’</blockquote>
<blockquote id="wish6" class="hang">‘It does not hurt to have those
features as well.’</blockquote>
<blockquote id="wish7" class="hang">‘One code base; fully
cross‐platform.’</blockquote>
<blockquote id="wish8" class="hang">‘You have to pick your battles.’</blockquote>
<blockquote id="wish9" class="hang">‘Once you get familiar with the
internal workings of our software, it becomes easy to use.’</blockquote>
<blockquote id="wish10" class="hang">‘Our specific target user group is: everyone.’</blockquote>
<blockquote id="wish11" class="hang">‘Our developers are very
experienced; they make the UI of their modules as
they see fit.’</blockquote>
<blockquote id="wish12" class="hang">‘We religiously adhere
to the <acronym>HIG</acronym>.’</blockquote>
<blockquote id="wish13" class="hang">‘You can do that by [writing, running]
a script.’</blockquote>
<blockquote id="wish14" class="hang">‘What do you mean “it’s
all connected”? we just don’t have the time for those bits
and pieces.’</blockquote>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>;
there is a <a href="http://blog.mmiworks.net/2013/12/12-you-can-do-to.html">new series</a> starting, again with a thought every workday.</p>
<p>And third, if you recognise that some of the wishful thinking is
practiced at your software project and you <em>can and want to</em> do
something about it, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will treat your case in total confidence.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2013/10/12-why-products-fail-enterprise.html">part three</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-18270287616115584492013-10-30T17:56:00.000+01:002013-11-16T13:36:48.297+01:0012 reasons why products fail, enterprise edition <p>Part three of the mini‐series I am running at the
moment on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>wishful thinking breeds failed products</i>. It distils what I have
witnessed and heard during 20 years in the (mobile) software industry.</p>
<p><span id="teaser">For this instalment I compiled a synergetic set of enterprise‐grade
wishful thinking</span>. By request, they are listed below for future reference.
<span id="teaser">I am curious if you recognise some of these</span>:</p>
<blockquote id="wish1" class="hang">‘Better play it safe, because it has
not been done before.’</blockquote>
<blockquote id="wish2" class="hang">‘Better play it safe, so it
won’t cause all these extra rounds of meetings.’</blockquote>
<blockquote id="wish3" class="hang">‘Better play it safe, because the
first feedback was rather reserved.’</blockquote>
<blockquote id="wish4" class="hang">‘Better play it safe, so we
get the OK.’</blockquote>
<blockquote id="wish5" class="hang">‘Better play it safe, because the
engineers say it cannot be done.’</blockquote>
<blockquote id="wish6" class="hang">‘Better play it safe, because that
code base is spaghetti.’</blockquote>
<blockquote id="wish7" class="hang">‘Better play it safe, so we all can
go home at five—and on 14:30 (<acronym>D</acronym>) / to the pub
(<acronym>GB</acronym>) on friday.’</blockquote>
<blockquote id="wish8" class="hang">‘Better play it safe, because the
blame will fall on us.’</blockquote>
<blockquote id="wish9" class="hang">‘Better play it safe, so we have
time for more features.’</blockquote>
<blockquote id="wish10" class="hang">‘Better play it safe, to pass the
usability test.’</blockquote>
<blockquote id="wish11" class="hang">‘Better play it safe, to pass the
regression test.’</blockquote>
<blockquote id="wish12" class="hang">‘Better play it safe, to not
jeopardise my promotion.’</blockquote>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh example of wishful thinking every workday.</p>
<p>And third, if you recognise that some of the wishful thinking is
practiced at your software project and you <em>can and want to</em> do
something about it, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will treat your case in total confidence.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2013/10/another-12-why-products.html">part two</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-66215336040139200832013-10-18T16:47:00.000+02:002015-08-11T18:06:45.323+02:00war and peace, the abridged UI version <p><span id="teaser">Not to worry, this is not going to be as lengthy as
<a href="https://en.wikipedia.org/wiki/Leo_Tolstoy">Tolstoy’s</a>
<a href="https://en.wikipedia.org/wiki/War_and_Peace">tome</a>.</span>
Actually, I intend this blog post to be shorter than usual.
<span id="teaser">But yes, my topic today is <em>war and peace</em> in
interaction design.</span></p>
<h3>peace</h3>
<p>I like to think that my work as an interaction architect makes the world a
better place.</p>
<p>I realise product makers’ dreams, designing elegant and captivating
embodiments they can ship. I save terminally ill software and websites
from usability implosion, and in the meantime get their makers a lot closer to
what they always intended.</p>
<p>On top of that, I provide larger organisations with instruments to reign in the
<a href="http://blog.mmiworks.net/search/label/why%20products%20fail">wishful thinking</a>
that naturally accumulates there, and to institute <acronym>QA</acronym> every
step along the way.</p>
<p>All of this is accomplished by harmonising the needs of product makers,
developers and users. You would think that because I deliver success;
solutions to fiendishly complex problems; certainty of what needs to be done;
and <em>(finally!)</em> usable software, working with these three groups is a
harmonious, enthusiastic and warm experience.</p>
<p>Well, so would I, but this is not <em>always</em> the case.</p>
<h3>war</h3>
<p>The animosity has always baffled me. I also took it personally: there
I was, showing them the light at the end of the tunnel of their own misery,
and they get all antsy, hostile and hurt about it.</p>
<p>After talking it through with some trusted friends, I have now a whole
new perspective on the matter. Sure enough, as an interaction architect I am
always working in a conflict zone, but <strong>it is not my
conflict</strong>. Instead, it is the tri‑party conflict between product
makers, developers and users.</p>
<dl>
<dt>The main conflict between product makers and users</dt>
<dd>Each individual user expects software and websites really to be made for
<em>me‐me‐me</em>, while product makers try to make it for as many
users as possible. Both are a form of greed.</dd>
<dd>There is also a secondary conflict, when users ‘pay’ the
product maker in the form of personal, behavioural data, and/or by
eyeballing advertisements—’nuff said.</dd>
<dt>The main conflict between product makers and developers</dt> <dd>Product
makers want the <em>whole</em> thing perfectly finished by <em>tomorrow</em>,
while reserving the right to change their mind, any given minute, on what this
<em>thing</em> is. Developers like to know exactly up front what all the
<em>modules</em> are they have to build—but not too exactly, it robs the
chance to splice in a cheaper substitute—while knowing it takes time,
four times more than one would think, to build software.</dd>
<dd>That this is a fundamental conflict is proven by the current fad for agile
development, where it is conveniently forgotten that there is such a thing as
<em>coherence and wholeness</em> to a fine piece of software.</dd>
<dt>The main conflict between developers and users</dt> <dd>This one is very
simple: who is going to do the work? Developers think it is enough to get the
technology running on the processing platform—with not too many crashing
bugs—and users are free to do the rest. Users will have no truck with
technology; they want refined <em>solutions</em> that
‘just work™,’ i.e. the developers do the work.</dd> </dl>
<p>All of this makes me
<a href="http://en.wikipedia.org/wiki/Jimmy_Carter">Jimmy Carter</a> at
<a href="http://en.wikipedia.org/wiki/Camp_David_Accords">Camp David</a>.
The interaction design process, the resulting interaction design and its
implementation are geared towards bringing peace and prosperity
to the three parties involved. This implies compromises from each party.
And for me to tell them things they do not like to hear.</p>
<dl>
<dt>Product makers need to be told</dt>
<dd><ul>
<li>to make real hard choices and define their target user groups
narrowly—it is not for everyone;</li>
<li>that they cannot play fast and loose with users’ data;</li>
<li>to take the long, strategic view on the product level, instead of trying
to micro‐manage every detail of its realisation;</li>
<li>to concentrate on the features that really <em>make</em> the product,
instead of a pile‑up of everybody’s wish lists;</li>
<li>to accept that they cannot have it <em>all</em>, and certainly not with
little effort and investment.</li>
</ul></dd>
<dt>Users need to be told that</dt>
<dd><ul>
<li>each of them are just part of a (very large) group and that
<em>in general</em> the needs of this group are addressed by
the product;</li>
<li>using software and websites takes a certain amount of investment
from them: time, money, participation and/or privacy;</li>
<li>software cannot read their minds; to use it they will need to input
rather exactly what they are trying to achieve;</li>
<li>quite a few of them are outside the target user group and
their needs will not be taken into consideration.</li>
</ul></dd>
<dt>Developers need to be told</dt>
<dd><ul>
<li>that we are here to make products, not just code modules;</li>
<li>no substitutes please, the <em>qualities</em> of what needs to be
built determines success;</li>
<li>users cannot be directly exposed to technology; an
opaque—user—interface is needed between the two;</li>
<li>if it isn’t usable, it does not work.</li>
</ul></dd>
</dl>
<p>No wonder everybody gets upset.</p>
<h3>peace</h3>
<p>How do I get myself some peace? Well, the only way is to obtain a
bird’s‐eye view of the situation and <em>to accept it</em>.</p>
<p>First, I must accept that this war is <em>inherent to any design
process and all designers are confronted by it</em>. Nobody ever really
told us, but we are <em>there</em> to bring peace and success.</p>
<p>Second, I have to accept that product makers, developers and users
get upset with my interaction design solutions for the simple reason that they
are now confronted with the needs of the other two parties. They had it
‘all figured out’ and now this turns up. (Yes, I <em>do</em>
also check if they have a point and discovered a bug in my design.)</p>
<p>Third, I have to see my role as translator in a different light. We
all know that product makers, developers and users have a hard time talking to
each other, and it is the role of the interaction architect to translate
between them.</p>
<p>It is now clear to me that when I talk to one of the parties involved,
I do not only fit the conversation to their frame of reference and speak
their language, but also represent the other two parties. There is some anger
potential there: for my audience because I speak in such familiar terms, about
unfamiliar things that bring unwelcome complexity; for me because tailored
vocabulary and examples do not increase acceptance from their side.</p>
<p>Accepting the <i>war and peace</i> situation is step one, doing something
about it is next. I think it will take some kind of <em>aikido move</em>;
a master blend of force and invisibility.</p>
<p>Force, because I am still implicitly engaged to bring peace and success,
and to solve a myriad of interaction problems nobody wants to touch. This must
be met head‑on, without fear.</p>
<p>Invisibility, because during the whole process it must be clear to all
three parties that they are not negotiating with me, but with
each other.</p>
<h4>postmortem</h4>
<p>That is it for today, I promised to keep it short. There are some
interesting kinks and complications in the framework I set up today, but
dealing with them will have to wait for another blog post.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com2tag:blogger.com,1999:blog-28919981.post-56636239527309405062013-10-09T10:49:00.001+02:002013-11-16T13:22:24.881+01:00another 12 reasons why products fail <p><span id="teaser">Part two of the mini‐series I am running at the
moment on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>wishful thinking breeds failed products</i>. It distils what I have
witnessed and heard during 20 years in the (mobile) software industry.</span></p>
<p>By request, here are the second dozen of these for
future reference. I am curious if you recognise some of this wishful thinking:</p>
<blockquote id="wish1" class="hang">‘A list is a list is a list. Why do
these two parts of our app need such a different design?’</blockquote>
<blockquote id="wish2" class="hang">‘Sure, it needs to be designed.
Let’s get a [student, intern] for that.’</blockquote>
<blockquote id="wish3" class="hang">‘Our usability sucks. To fix that,
maybe we can take some guidelines and apply them religiously.’</blockquote>
<blockquote id="wish4" class="hang">‘The features our most‐valued
customers ask for are implemented asap, future plans be damned.’</blockquote>
<blockquote id="wish5" class="hang">‘The development is almost finished,
now we need some design on top to jazz it up.’</blockquote>
<blockquote id="wish6" class="hang">‘We are the typical users.’</blockquote>
<blockquote id="wish7" class="hang">‘Let’s get the designer(s) to
deliver 3 proposals, then we pick—and mix—what
we like.’</blockquote>
<blockquote id="wish8" class="hang">‘For that you can export the data
to excel.’</blockquote>
<blockquote id="wish9" class="hang">‘We did do user research; we asked
them what they liked and not, and what was missing.’</blockquote>
<blockquote id="wish10" class="hang">‘We have been doing it like this for
many years.’</blockquote>
<blockquote id="wish11" class="hang">‘We design in code.’</blockquote>
<blockquote id="wish12" class="hang">‘Really, users could also put some
effort into using our software.’</blockquote>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh example of wishful thinking every workday.</p>
<p>And third, if you recognise that some of the wishful thinking is
practiced at your software project and you <em>can and want to</em> do
something about it, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will treat your case in total confidence.</p>
<p class="double"><i>ps:</i> you can check out
<a href="http://blog.mmiworks.net/2013/09/12-reasons-why-products.html">part one</a>
if you missed it.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-8828823783058957442013-09-23T11:31:00.000+02:002013-10-09T19:43:08.467+02:0012 reasons why products fail <p><span id="teaser">At the moment I am running this mini‐series on the usual social
channels—<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a> and
<a href="http://www.xing.com/profile/peter_sikking">xing</a>—called
<i>wishful thinking breeds failed products</i>. It distils what I have
witnessed and heard during 20 years in the (mobile) software industry.</span></p>
<p>By request, I now put the first dozen of these into a blog post for
future reference. I am curious if you recognise some of this wishful thinking:</p>
<blockquote id="wish1" class="hang">‘Just ask the customers, they
know best.’</blockquote>
<blockquote id="wish2" class="hang">‘Users will love our hot, new
technology, they will be queuing around the block.’</blockquote>
<blockquote id="wish3" class="hang">‘With zero (major) bugs in the
tracker, this feature must be working well.’</blockquote>
<blockquote id="wish4" class="hang">‘But why? nobody ever complained
about that.’</blockquote>
<blockquote id="wish5" class="hang">‘We’ll leave that choice to
our users, via a setting in the preferences.’</blockquote>
<blockquote id="wish6" class="hang">‘In this phase of development,
usability is a nice‑to‑have.’</blockquote>
<blockquote id="wish7" class="hang">‘Our product designers are part of
the [marketing, engineering, product, operations]
department.’</blockquote>
<blockquote id="wish8" class="hang">‘This is what users are used to; we
better not change it.’</blockquote>
<blockquote id="wish9" class="hang">‘We started out by scratching our
itch; today, we still make it exactly how
we like it.’</blockquote>
<blockquote id="wish10" class="hang">‘With all this quantitative
tracking data, we know exactly what works, and
what not.’</blockquote>
<blockquote id="wish11" class="hang">‘For our next version, we will
refactor a lot of the code; a huge effort, so no other
changes.’</blockquote>
<blockquote id="wish12" class="hang">‘I can’t see why we would do
it differently from how [facebook, microsoft, google, adobe]
do it.’</blockquote>
<h3>ask not what this blog can do for you…</h3>
<p>Now, what can <em>you</em> do? First of all, you can spread the word; share this
blog post. Second, the series continues, so I invite you to connect via
<a href="http://twitter.com/peter_works">twitter</a>,
<a href="https://plus.google.com/101901813675356116026">g+</a>,
<a href="http://www.linkedin.com/in/petersikking">linkedin</a>, or
<a href="http://www.xing.com/profile/peter_sikking">xing</a>, and get
a fresh example of wishful thinking every workday.</p>
<p>And third, if you recognise that some of the wishful thinking is
practiced at your software project and you <em>can and want to</em> do
something about it, then
<strong><a href="mailto:%70%65%74%65%72%40%6d%6d%69%77%6f%72%6b%73%2e%6e%65%74">email</a>
or call us</strong>. We will treat your case in total confidence.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-50832763374951248282013-06-08T14:13:00.000+02:002013-10-09T10:52:01.072+02:00teaching interaction /13 <p>At the end of March I was at the
<a href="http://www.fhv.at/"><acronym>FH</acronym> Vorarlberg</a>, Austria
to teach my course, <i>interaction design for the real world</i>.
<span id="teaser">As always, things evolved further: last year I had written the
<a href="http://gui.gimp.org/index.php/Vision_briefing">product vision briefing</a>
for <a href="http://blog.mmiworks.net/search/label/GIMP"><acronym>GIMP</acronym></a>,
the software project that supplies the course with real‐life interaction
design challenges. This briefing started to play a major role
this year.</span></p>
<p>In a very natural manner, the
<a href="http://gui.gimp.org/index.php/Vision_briefing#value_.2B_traits">value
and traits of <acronym>GIMP</acronym></a>, as described in the briefing,
became central to all evaluation and design work done during the course.
Though not 100% premeditated, this is a very welcome development and I will
certainly expand on it next year.</p>
<p>I also had the pleasure of introducing another interaction design taboo
phrase. In the past two years they were
‘<a href="http://blog.mmiworks.net/2011/07/teaching-interaction-11.html">intuitive</a>’ and
‘<a href="http://blog.mmiworks.net/2012/05/teaching-interaction-12.html">the user</a>.’
This year it was ‘we tried,’ I have seen it used often
enough by my students in reports. Interaction designers do not try, they
<em>make</em>. Yes, not everything works <em>exactly</em> as expected, that is what
iteration is for. But in general interaction designers are in a unique position
for <em>making</em>, it work.</p>
<h3>I just can’t get enough</h3>
<p>The <acronym>GIMP</acronym> design challenge I picked this year was the
<a href="http://docs.gimp.org/2.8/en/gimp-tool-align.html">align tool</a>.
It can be used to align—left, middle, right, top, centre,
bottom—image layers with various image objects (layer, path, image,
selection, channel). This relatively compact tool needs an interaction
redesign, it has never received any design love.</p>
<p>While preparing the course, I checked out the tool. Within ten minutes
I was asking myself why only layers can be aligned—i.e. moved—and
not all the other objects (paths, channels, etc). Also the whole distribute
mode does not actually distribute (objects evenly between themselves), it just
aligns them with some extra offset. It became clear that the align tool is
woefully underpowered: it has <em>not enough functionality.</em></p>
<p>How quaint. Normally interaction designers have to fight too much and
gratuitous functionality, and make it manageable. Conversely, during this
course the student design teams had to concern themselves with what
functionality to <em>add</em>, to make the align tool fit for use.</p>
<h4>scenarios + variants</h4>
<p>To flesh out the essential use of the align tool, we made a few user
scenarios:</p>
<dl>
<dt>just align</dt>
<dd>this is as simple as it gets: align top/left/etc. of one object
(layer, path, selection, channel) with another (all of the above, plus image).</dd>
<dt>keeping things together</dt>
<dd>pick multiple objects that belong together, e.g. a layer with a corresponding
mask, and align as one unit with another object; the same for multiple of
these units.</dd>
<dt>true distribution</dt>
<dd>distribute objects evenly among themselves, or in an absolute way with a
fixed offset.</dd>
<dt>all together now</dt>
<dd>this is as complicated as it can get: combined alignment and distribution of
combined units and single objects.</dd>
</dl>
<p>The students used these scenarios for their evaluation of the interaction
of the existing tool. With the gained insight into the good and the bad, the
students were then ready to brainstorm better solutions. Apart from ideas for
fleshing out the functionality, I asked the students to brainstorm two
variants of the tool: one as it is now—a toolbox tool—the other
<em>anything but</em> a toolbox tool (i.e. using only the menu bar and dockable
dialogs).</p>
<h4>hands‑off</h4>
<p>This was in response to the fact that the current align tool is not much of
a toolbox tool. It does not let users change things hands‑on on the
canvas (e.g. like paint tools do). On a higher level, it simply does not
<em>feel</em> like a toolbox tool. The question then simply becomes: should
the align tool be in the toolbox at all? This is what I let the students
explore.</p>
<p>This exploration set the student teams up for their reasoned decision on
which approach to take—toolbox tool or not—when they moved to the
solution design phase. By exploring diametrical opposites they did not only
got to know the potential of either solution, they also learned <em>more</em>
about either solution, from studying the opposite.</p>
<p>As you will see in a moment, all four teams chose to design the align tool
for the toolbox, with some teams adding non‑toolbox interaction to
the mix.</p>
<h3>four team results</h3>
<p>And now the design results of the student teams. The work of all four teams
is available under the
<a href="http://www.gnu.org/copyleft/fdl.html">GNU Free Documentation License 1.2</a>.
I will present them in team order.</p>
<h4>team one</h4>
<ul>
<li>members: Allison Cook, Dominic Berchtold + Eva‑Yola Hajdu</li>
<li><a href="http://mmiworks.net/pics/blog12/13team1.pdf">design concept document</a> (pdf, 1.2 MB)</li>
</ul>
<p>Team one gets straight to the point where it comes to making the align tool a
hands‑on tool. Layers can be grabbed and moved around and magnetic
points will perform the alignment:</p>
<img style="margin-left : -4px;" src="http://mmiworks.net/pics/blog12/13team1magnet.jpg"
alt="two rectangles with magnetic points" width="195" height="185"/>
<p>This is a good realisation of the ‘just align’ <em>spirit</em> of
the first user scenario. For more complex situations, involving more layers,
the team requisitioned the layers dialog, which changes appearance to reflect
that (right):</p>
<a href="http://mmiworks.net/pics/blog12/13team1layersL.jpg">
<img src="http://mmiworks.net/pics/blog12/13team1layers.jpg"
alt="tool options, canvas and layers dialog" width="380" height="124"/></a>
<p>On the left, in the tool options, users can see the list of layers which have
been selected for manipulation and unselect them there without having to dig around
either on the canvas or the layers dialog.</p>
<h4>team two</h4>
<ul>
<li>members: Dylan Burns, Paula Hidalgo + Nora Huber</li>
<li><a href="http://mmiworks.net/pics/blog12/13team2.pdf">design concept document</a> (pdf, 2.3 MB)</li>
</ul>
<p>Team two put their minds towards providing <em>quite</em> a few ways to
align and distribute (or disperse, as they called it). There is the objects
mode, which further develops the existing align tool:</p>
<a href="http://mmiworks.net/pics/blog12/13team2objectsL.jpg">
<img src="http://mmiworks.net/pics/blog12/13team2objects.jpg"
alt="objects mode tool options and the canvas with numbered objects"
width="380" height="306"/></a>
<p>And then there is the points mode, which lets users set a point, a marker
on each object that needs to be aligned with a reference point (the star):</p>
<a href="http://mmiworks.net/pics/blog12/13team2pointsL.jpg">
<img src="http://mmiworks.net/pics/blog12/13team2points.jpg"
alt="points mode tool options and the canvas with objects with points placed,
and the star reference" width="380" height="307"/></a>
<p>This takes into account that in pixel‐based applications
like <acronym>GIMP</acronym>, the ‘edge’ or ‘centre
point’ of subject matter is not necessarily that of the layer, path or
mask. Apart from the two modes, also magnetic snapping—similar to
team one—is part of the design.</p>
<img src="http://mmiworks.net/pics/blog12/13team2options.jpg"
alt="padding, distance and box tool options" width="186" height="65"/>
<p>Nice and compact is their design of three different ways to distribute
objects in the tool options. The Box mode lets users define a rectangle on the
canvas to set up distribution.</p>
<h4>team three</h4>
<ul>
<li>members: Florian Rehlendt, Linda Latzelsberger,
Madeleine Mouton + Lizzie Hinojosa Allen</li>
<li><a href="http://mmiworks.net/pics/blog12/13team3.pdf">design concept document</a> (pdf, 508 KB)</li>
</ul>
<p>Team three expanded align in three new directions:</p>
<img src="http://mmiworks.net/pics/blog12/13team3shapes.jpg"
alt="paths, shapes and templates to align with" width="380" height="49"/>
<p>The outcome of these three are shown below. Align‐along‐path
(middle) makes very good use of the path concept:</p>
<a href="http://mmiworks.net/pics/blog12/13team3alignL.png">
<img src="http://mmiworks.net/pics/blog12/13team3align.png"
alt="aligning objects with a circle, a wavy path and a grid layout" width="285" height="382"/></a>
<p>Team three allows the centre point simply to be moved. As stated above, it
is not necessarily located in the centre of a layer or mask (left):</p>
<img src="http://mmiworks.net/pics/blog12/13team3preview.png"
alt="moving the centre point and a alignment preview" width="380" height="244"/>
<p>On the right we see the preview option demonstrated, invoked by hovering over
an align or distribution button.</p>
<h4>team four</h4>
<ul>
<li>members: Sabina Loacker, Barbara Nader, Nicole Paulo +
Thomas Windisch</li>
<li><a href="http://mmiworks.net/pics/blog12/13team4.pdf">design concept document</a> (pdf, 2.4 MB)</li>
</ul>
<p>Team four designed a different version of working hands‑on on the
canvas. Their reference object shows an ‘alignment map’; clicking one
of these six lines aligns other highlighted objects with it:</p>
<img src="http://mmiworks.net/pics/blog12/13team4map.png"
alt="an object rectangle with lines going through the sides and centre"
width="190" height="190"/>
<p>They extended this to the edges of image canvas; click them to align
objects with them:</p>
<img src="http://mmiworks.net/pics/blog12/13team4canvas.jpg"
alt="clicking a symbol at the edge of the canvas" width="279" height="183"/>
<p>Good to see that team four allowed for different horizontal and vertical
offsets and clearly shows these can be negative:</p>
<img src="http://mmiworks.net/pics/blog12/13team4offset.jpg"
alt="input fields and sliders for offsets in the tool options" width="190" height="190"/>
<h4>postscript</h4>
<p>What started as fleshing out an unassuming tool turned into serious design
work when user needs entered the picture. At the end of the final design day,
one of the students said <em>‘there are just so many things in my
head!’</em> Yes, that is what designing is about: connecting many,
many things.</p>
<p>Again I had a great week at the <acronym>FH</acronym> in Dornbirn this year.
I would like to thank all the students for the hard work they put in and for the
energy they returned.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-19061536889907266632013-05-23T22:51:00.000+02:002015-06-11T12:54:39.401+02:00design lessons with Daft Punk <p>I am sure you have noticed the
<a href="http://en.wikipedia.org/wiki/Daft_Punk">Daft Punk</a> marketing
master plan that is taking over all media channels at the moment. And I
admit that I am happy to consume—and inhale—anything
(semi‐)intelligent that is being written about them.</p>
<p>Yesterday I read this
<a href="http://www.guardian.co.uk/music/2013/may/19/daft-punk-release-a-new-album">Observer interview</a>
with the ‘notoriously shy French duo.’
<span id="teaser">Afterwards, intuition told me there was something
vaguely familiar about what they had said. I checked again and sure
enough, plenty of it applies to (interaction) design.</span></p>
<h3>punk rules, OK?</h3>
<p>Below are Daft Punk quotes I lifted from the article, followed by
what I associate with each. There are also a couple of cameo appearances by
hit‑production legend
<a href="http://en.wikipedia.org/wiki/Nile_Rodgers">Nile Rodgers</a>.</p>
<blockquote class="hang solo">‘The music that’s being done today has
lost its magic and its poetry because it’s rooted in everyday life and
is highly technological.’</blockquote>
<p>Wow, not the most hands‑on quote to start with. But I swore that
I’d present them in the order they appear in the article. With the
mentioned ‘magic and poetry’, I associate <em>fantastic</em>
design work. This means sweeping solutions, for which there needs to be at
least one designer on the project with a big‐picture view.</p>
<p>Being constantly ‘rooted in everyday life’—e.g.
<em>relying</em> on testing (<small>A/B</small> or usability); or working
piecemeal, or driven by user requests, or in firefighter mode—shortens
the horizons and shrinks the goals. It surely programs the project for
mediocrity, i.e. humdrum, incremental solutions.</p>
<p>Every user has to deal every day with software that ‘is highly
technological.’ Everybody thinks this sucks. Making software is highly
technological when one is staring at code; when thinking about code; when
taking prototyping capabilities into account; when technology informs the
interaction, verbatim. Designing great interaction means not making any of
these mistakes.</p>
<blockquote class="hang solo">‘In early interviews they came across as
suspicious and aloof. “It’s because you’re 18 and you feel
maybe guilty: why are we chosen to do these things?” says Thomas.
“There’s definitely reasons to feel less uncomfortable now.
It’s one thing to say you’re going to do it and another to have
done it for 20 years.”’</blockquote>
<p>Now that is the voice of experience talking. The first part of it is this
early phase; fresh out of school and real (work) life is starting. This
suspicion of one’s own talents, entering a company, scene or industry
and expecting the folks around you to <em>be</em> like you, <em>see</em>
things like you. And then they don’t. Very confusing, who is
wrong here?</p>
<p>The second part is having ‘done it for 20 years.’ If that
involved a portfolio of successful work; continuous self‐development;
the discovery of what a difference ‘being experienced’ makes and
getting to know a few peers, then it has become more comfortable to be a
designer. Just don’t get too comfortable; make sure every new project
you take on challenges and develops you.</p>
<blockquote class="hang solo">‘The only secret to being in control is to have
it in the beginning. Retaining control is still hard, but obtaining control is
virtually impossible.’</blockquote>
<p>The first level where this holds is getting a design implemented. Quite
often developers like to first put some temporary—and highly
technological—interaction while they sort out the non‑UI code.
The real design will be implemented later. Then time ticks away, the design
lands in a drawer and the ‘temporary’ UI gets shipped.</p>
<p>I do not think this is a malicious trick, but it happens so
often that I do not buy it anymore. The only secret to getting interaction
design implemented is to do it in the beginning.</p>
<p>The second level is that of the overall collaboration; ‘obtaining
control is virtually impossible,’ no matter how big a boost a designer
has given the project. So one has to start out with control from the
beginning, it has to be endowed by the project leadership. And then one has to
work hard to retain it.</p>
<blockquote class="hang solo">‘Guy‑Man, who designed the artwork, says
that Thomas is the “hands‑on technician” while he is the
“filter”: the man who stands back and says
<i>oui</i> or <i>non</i>.’</blockquote>
<p>Filter is the stuff designers are made of. In the case of interaction
designers it means filtering out of all the things users say, the things they
actually need. It means saying <i>non</i> to many things that are simply
technologically possible, but useless, and <i>oui</i> to exactly <em>that</em>
what realises the product, addresses users needs and is, yes, technologically
possible.</p>
<p>Being the filter does not always make you friends, having to say <i>non</i>
to cool‐sounding initiatives that in the bigger scheme of things are
incredibly unhelpful. But being a yes‑man makes an ineffective designer,
with non‑designed results.</p>
<p>Making software is not a game with unlimited time and resources; user
interaction is not one with unlimited screen space and communication bandwidth. A
filter is crucial.</p>
<blockquote class="hang solo">‘“The genius is never in the writing,
it’s in the rewriting,” says Rodgers. “Whenever they put out
records I can hear the amount of work that’s gone into them—those
microscopically small decisions that other people won’t even think
about. It’s cool, but they massage it so it’s not just
cool—it’s amazing.”’</blockquote>
<p>I learned some years ago that it is not only the <small>BIG</small> plans
and sweeping solutions that make a master designer. It is also in the details.
<em>All</em> the tiny details.</p>
<p>All these ‘microscopically small decisions’ have to be taken in
the way that strengthen the overall design, or else it will crumble to
dust. This creates tension with all the collaborators, who ‘won’t
even think about’ these details. They cannot see the point, the crumbling.
Masters do.</p>
<blockquote class="hang solo">‘We wish people could be influenced by our
approach as much as our output. It’s about breaking the rules and doing
something different rather than taking some arrangements we did 10 years
ago that have now become a formula.’</blockquote>
<p>Design is not a formula, not a sauce you pour over software. Design is a
process, performed by those who can. A designer cannot tell upfront what the
design will be like, but knows where to start, what to tackle and when it
is done. That sounds trivial, but for non‑designers these four points
work exactly opposite.</p>
<p>Apply the design process to a unique (i.e. non‑copycat) project and you
will get an appropriate and unique design. Blindly applying this design
to another project is by definition inappropriate.</p>
<blockquote class="hang solo">‘“Computers aren’t really music
instruments,” he sniffs. “And the only way to listen to it is on a
computer as well. Human creativity is the ultimate interface. It’s much
more powerful than the mouse or the touch screen.”’</blockquote>
<p>This quote hits the nail on the head by setting the flow of creativity
between humans as the baseline and then noting how computer interfaces are
completely humbled by it. It is too easy to forget about this when your
everyday world is making software.</p>
<p>The truth about software for designers (of music, graphics and other media)
is that not much of it is designed—the interaction I mean, although it
may <em>look</em> cool. Being software for a niche market makes it
<a href="http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html">armpit of usability</a>
material: developers talking directly to users, implementing their feature
request in a highly technological way.</p>
<p>To make an end to this sad state of affairs, a design process needs to be
introduced that is rooted in a complete—but
<em>filtered</em>—understanding of the activity called human
creativity.</p>
<blockquote class="hang solo">‘Enjoying the Hollywood analogy, Thomas says
Daft Punk were the album’s screenwriters and directors while the guest
performers were the actors, but actors who were given licence to write their
own lines.’</blockquote>
<p>I am also enjoying that analogy, and the delicate balance that is implied.
On the one hand, interaction designers get to create the embodiment of the
software ‘out of thin air’ and write it down in some form of
specification, the screenplay. Being in the position of seeing how <em>everything</em>
is connected, it also falls naturally to them to direct the further
realisation, by developers and media designers.</p>
<p>If that sounds very bossy to you, it is balanced by the fact that these
developers and media designers already <em>have</em> complete ‘licence
to write their own lines.’ For developers every line of code they write
is literary theirs.</p>
<p>The delicate balance depends on developers and media designers being able
to contribute to the interaction design process—in both meanings of that
phrase. And it depends on all written lines fitting the screenplay.</p>
<blockquote class="hang solo">‘“What I worked on was quite bare bones
and everything else grew up around me,” says Nile Rodgers. “They
just wanted me to be free to play. That’s the way we used to make
records back in the day. It almost felt like we’d moved back
in time.”’</blockquote>
<p>This is what design processes are about; to create a space where one is
free to play. This in the dead‐serious context of solving the
problem. Play is used to get around a wall or two that stand between
the designer and the solution for making it <em>work</em>.</p>
<p>It takes a ‘quite bare‐bones’ environment to be free:
pencil and paper in the case of interaction design. That may ‘feel like
moving back in time’ but it is actually really liberating; it offers a
great interface for human creativity. Once you got around those walls and hit
upon the solution, every part of the design can grow up around what
you <em>played.</em></p>
<p>And on that note, I’ll finish today’s blog post. </p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-90310403455817889702013-05-13T13:58:00.000+02:002013-06-08T23:04:21.831+02:00masterclass in san francisco <p>The day after
<a href="blog.mmiworks.net/2013/04/collisions-in-software-projects-and.html">Volkswagen + Wolfsburg</a>
I was on my way to San Francisco. I had been invited by the
<a href="http://www.cca.edu/">California College of the Arts</a>
(<acronym>CCA</acronym>) for their Dutch Design Week, ‘a series of events
celebrating Dutch Design and fostering exchange between Dutch and American
Designers.’</p>
<p><span id="teaser">My personal highlight of these events was a
two‐day masterclass for design graduates and interaction design
undergraduates. Not only because of the intense and re‑energising work
with the <acronym>CCA</acronym> students, but also because I learned something
new from two cases of unintended consequences.</span></p>
<h3>begin the beguine</h3>
<p>While I was planning the class, Kristian Simsarian—chair of the
interaction design program at <acronym>CCA</acronym>—encouraged me to
pick a topic which I am passionate about. So I picked two:
<a href="http://mmiworks.net/portfolio/">product realisation</a> and
<a href="http://blog.mmiworks.net/search/label/mobile">mobile</a>. The last
decade these have been the most important themes in my design practice, with
the highest impact.</p>
<p>So the masterclass was going to consist of designing a proper mobile
website or app for a software product, a service, website or organisation.
Question was: which one?</p>
<h4>uncanny valley</h4>
<p>I am not comfortable with structuring my teaching around imaginary
projects. Only when there are one or more persons inside a project who burn to
make something valuable, it is viable for designers to work on it and
<em>realise</em> this goal.</p>
<p>So instead of making up an imaginary project for this class, I asked
the participating students to bring their own project, one <em>they</em> are
<em>passionate</em> about. I was curious to see what they would bring in:
could be some app they love but wanted to redesign, or a local community
project. At the end each student brought a personal project to work on,
some of them with a local (transport/biking) flavour.</p>
<h3>on the one</h3>
<p>Fast‐forward to the first morning of the masterclass. The
<acronym>CCA</acronym>’s <acronym>SF</acronym> building is like a
cathedral part‐filled with a labyrinth of cosy spaces to teach and work.
Next door to my class was the one of industrial designer
<a href="http://www.joine.nl/en/index.php?id=2&office=2">Maarten Baptist</a>.
Right in front of us, the floor of the ‘nave’ filled up with the
graphic design students of Marijke and Chantal, i.e.
<a href="http://www.cobbenhagenhendriksen.nl/">Cobbenhagen Hendriksen</a>,
working on posters. Everyone was inspired.</p>
<p>After a riveting introduction by Alexander Baumgardt—who had been
instrumental in bringing me over for the week—it was time for me to get
to know the students, seven graduates and five undergrads. I am always
interested in the reason why each chose to participate, it tells me something
about this student and her/his expectations, and the future of
my industry.</p>
<h4>get with the program</h4>
<p>I then explained the main building blocks of the class, product
realisation and mobile, and two auxiliary ones: ‘design is solving the
problem’ and ‘designing is done pencil on paper.’
I wove these together with an overview of my career, to show where they
are coming from and why they play such an important role in
my practice.</p>
<img class="cited" src="http://mmiworks.net/pics/blog12/ccaClass.jpg"
alt="Peter Sikking in front of the interaction design class"
width="380" height="292"/>
<cite>explaining the tactical deployment of user scenarios;
photo © Kathleen Moynahan</cite>
<p>Next, I structured our work for the first day. We started off with the
<a href="http://mmiworks.net/wedo/product.html">product phase</a>; building a
foundation for the design work: product vision; functionality overview; user
scenarios; expert evaluation. First up was the method that I see as crucial for
product realisation: compiling a product vision.</p>
<h3>vicious games</h3>
<p>Experience tells me that it is incredibly hard for project insiders to
define their vision; it’s like pulling teeth. It also takes a long time;
weeks of pulling teeth. I did not have the time for this, although I had
created the situation that every student entered the class as a full insider
of her/his own project.</p>
<p>What I needed was what every project needs: a moderator to tease the vision
out of the project insiders. Luckily I had a class full of potential moderators.
Product realisation means working from a vision, thus it became
natural to go through the exercise of moderating one.</p>
<h4>1 + 1 = 2</h4>
<p>During the morning, I introduced the
<a href="http://mmiworks.net/wedo/product.html">product vision</a>
method and told the story of how I developed it years ago. I showed the
<a href="http://blog.mmiworks.net/2010/03/working-on-vision-with.html">Krita
example</a>—long live <em>open</em> working—and explained what
each part means, down to single words. Then I asked the students to work
in pairs.</p>
<p>Because I found the interaction specialisation vs. maturity asymmetry in my
class interesting, I asked the undergrads to pair up with a graduate
student, just to mix things up. Looking back I can report that collaboration
was exemplary.</p>
<p>Within each pair, one would take the role of moderator, helping the
other—insider to her/his own project—to formulate a vision. Then
they swapped roles.</p>
<h4>altogether</h4>
<p>Getting a product vision together takes time and each pair had to formulate
two of them. As a result we spent a couple of hours on this method. Apart from
doing <acronym>Q</acronym>+<acronym>A</acronym> and guidance with the six
pairs, I also held two rounds of discussion with the
complete class.</p>
<p>In these discussions we spoke about how we were doing, what we were
observing and experiencing, and I explained the more tricky parts of
a product vision. From the reaction of my students, I got my first dose of
unintended consequences.</p>
<h4>1 + 1 = 4</h4>
<p>By now you know that I had the students work on a vision in both moderator
and insider roles just to stand a chance of getting it done.
I <em>could</em> have predicted that by playing both roles they would get
twice the insight into the product vision method.</p>
<p>But judging from the overwhelming reaction of my students, I seemed to
have a struck a <em>quadratic</em> effect. They were enthusiastic and
‘getting it’ as if they just had four times the insight. That
really made my day.</p>
<h4>can you dig it?</h4>
<p>Here are three product vision statements made in the class:</p>
<blockquote class="hang">‘The Thrive App gives a voice to household
plants. Thrive lets busy, novice plant owners know their plant’s
well‐being via a paired sensor in the soil and recommends appropriate
care through the voice of the plant.</blockquote>
<blockquote class="hang">‘Thrive notifies owners of their plant’s
vitals in real time. Thrive connects people to nature in a small way by
creating an emotional bond between people and
their plants.’</blockquote>
<cite>vision © Ramunė Rastonis, moderated by Allison Leach</cite>
<blockquote class="hang">‘<i>Echosphere</i> is a mobile application that
creates and controls sounds based in your movement.</blockquote>
<blockquote class="hang">‘By combining live movement with sound and
visuals, it helps an older audience reawaken their
sense of play.</blockquote>
<blockquote class="hang">‘<i>Echosphere</i> is an individualized,
immersive experience that encourages breaking out of
analytical thought.’</blockquote>
<cite>vision © Kathleen Moynahan, moderated by Evan Litvak</cite>
<blockquote class="hang">‘MyWay is a smartphone app to optimize the
daily use of public transportation. Users can personalize their regular
destinations and schedules. The app keeps track of the public transportation
times and provides accurate feedback to the user, sending updates. It learns
from users’ behavior and automates their routine
trip plans.</blockquote>
<blockquote class="hang">‘It is meant for San Franciscans, in their 20’s
to 50’s, who use public transportation, own smartphones and are familiar with
the streets of San Francisco. The users have busy schedules, commute daily
with normally 2 to 4 regular destinations.</blockquote>
<blockquote class="hang">‘With MyWay people will be able to clear their
minds from repetitive tasks of keeping tracks of their time to catch public
transportation. It will free the user from the burden of keeping constant eye
on the transit schedule.’</blockquote>
<cite>vision © Tatsiana Siadneva, moderated by Francis Nakagawa</cite>
<p>It is clear what each of these three is about and what value it aims to deliver.
And that is the point of a vision.</p>
<h3>bat man</h3>
<p>On the second day of the masterclass the accent moved to mobile
interaction. It was time to lead the students to a series of hard mobile
design choices that they had to make for their project. For instance:</p>
<dl>
<dt>mobile website or app?</dt>
<dd>This choice should not be based on how cool, or confident one feels
designing it, but on what is best implementing the product vision. </dd>
<dt>fragmentation</dt>
<dd>With limited time available for
this class, I made the students pick one platform and one screen size
(‑range,
<a href="http://blog.mmiworks.net/2012/09/responsive-web-layouts-filling-the.html#finalgap">in cm/inches</a>
of course) to design for. In the real world, each (supported) combination of
these two needs a separate, optimised design.</dd>
<dt>the <strong>nr.1</strong> issue in mobile</dt>
<dd>a.k.a. the battery. It has been <em>the</em> issue for decades. As
interaction designer—i.e. designer of ‘the whole
thing’—one will either be confronted with severe limitations set
by the platform on how much the app/site can be ‘alive’ all the
time, or there are no limits and one has the full responsibility to not drain the
battery, all the time.</dd>
</dl>
<p>The overall goal of the masterclass was to design a solutions model; i.e.
the broad‐strokes plan that solves the main design challenges, plus a
strategy to design the rest. A complete (draft) design of even a small app
would have been too much work for our two days.</p>
<h4>go west</h4>
<p>I encouraged my students to explore and brainstorm before working reductive
and settling for a solution. But in practice, quite a few of them settled
too quickly.</p>
<p>So I challenged these students: ‘I see your design hinges
largely on <acronym>XYZ</acronym>, It would be good if you brainstorm a few
ideas that do not involve <acronym>XYZ</acronym>. Either you’ll find
something better than your current plan, or you will learn valuable lessons
about <acronym>XYZ</acronym>.’</p>
<a href="http://mmiworks.net/pics/blog12/thriveL.jpg">
<img class="cited" src="http://mmiworks.net/pics/blog12/thrive.jpg"
alt="several sheets of paper with interaction sketches"
width="380" height="253"/></a>
<cite><a href="http://ramunerastonis.com/portfolio/portfolio/thrive-app-concept/">Thrive
interaction</a> sketches, © Ramunė Rastonis</cite>
<h4>go next</h4>
<p>Working with the students showed a lot of variation. Each had her/his own pace,
project, approach, and design. I enjoyed immensely working with each
individually and I am sure all of us would have enjoyed a couple of days
more of designing together. Then there was
the second case of unintended consequences.</p>
<p>The feedback of most students was that they were going to continue working
on their project. This is really different than usual, where the project gets
dumped the moment the class is over. Why was it different this time? Ah, because
each of them brought a <em>personal</em> project.</p>
<p>All in all it is very rewarding to see the impact of the masterclass. To
see how the project of every student made at least two steps in the
right direction. To see how the students ‘got’ something out of it
that they can use during their design careers.</p>
<a href="http://mmiworks.net/pics/blog12/echosphereL.png">
<img class="cited" src="http://mmiworks.net/pics/blog12/echosphere.jpg"
alt="a glimpse of a mobile interaction flow diagram"
width="380" height="267"/></a>
<cite>Echosphere interaction wireframes, worked out after the class,
© Kathleen Moynahan</cite>
<h3>postscript</h3>
<p>I did a panel discussion and a <acronym>Q</acronym>+<acronym>A</acronym>
session with first year interaction design students during the
<acronym>CCA</acronym> Dutch Design Week. I also met a lot of interesting
people. But the masterclass stands as my personal highlight because from all
the feedback I got, it was clear that both the students and the
<acronym>CCA</acronym> got a real kick out of it. And so did I.</p>
<p>I would like to thank the students for their hard work; Tatsiana, Kathleen
and Ramunė for allowing me to share their work here; Alexander Baumgardt for
getting the ball rolling; and all at the <acronym>CCA</acronym> and the Dutch
consulate who enabled this trip.</p>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0tag:blogger.com,1999:blog-28919981.post-25554236257610539162013-04-26T11:37:00.000+02:002013-04-26T13:28:01.463+02:00collisions in software projects… and a Volkswagen bus <p>A week or two ago I was the guest of Volkswagen, in their hometown of
Wolfsburg. They had asked me to lecture on in‑house software projects,
friction and usability. Great question, could fill many an hour answering it.
With one hour at my disposal, I picked one main aspect.
Here we go.</p>
<h3>the fashion trade</h3>
<p>Usually I design interaction for software <strong>products</strong>;
off‐the‐peg software so to say: desktop applications,
<a href="http://mmiworks.net/portfolio/index.html#searchmetrics">in browsers</a>,
and since 1997 also
<a href="http://blog.mmiworks.net/search/label/mobile">mobile</a>. A recent
twist are
<a href="http://blog.mmiworks.net/2012/11/a-survival-for-designing-in-service.html">services</a>,
for instance
<a href="http://mmiworks.net/portfolio/index.html#unusuals">social networks</a> or
<a href="http://mmiworks.net/portfolio/index.html#o2"><acronym>B2B</acronym> websites</a>.</p>
<p>A quite different world is that of software <strong>projects</strong>; bespoke
software, made to measure for clients and—hopefully—its users too.
Comparing software products and projects, there is remarkable effect that I want
to address in this blog post.</p>
<h4>slidin’ down</h4>
<p>Below we see from left to right a continuum of software specialisation:
from general (email, web surfing), via specialised (software for doctors, or
engineers) to bespoke projects. Plotted against that is their usability,
<em>in general</em>:</p>
<img src="http://mmiworks.net/pics/blog12/downhill.png"
alt="usability ramps down as software gets more specialised"
width="380" height="234"/>
<p><span id="teaser">I have
<a href="http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html">blogged before</a>
about this ‘armpit of usability,’</span> its cause and effect.
<span id="teaser">Today I will go into why software projects are located at
its smelliest end. For this, we need to take a look at the <strong>three
worlds</strong> that collide in software projects, what they
<strong>need</strong>, and <strong>offer</strong>.</span></p>
<h3>clients</h3>
<p>The first world we will take a look at is that of clients. This is logical
because it is clients who instigate software projects (there are also
illogical ways to start a software project—e.g. have to spend the budget before
year’s end, ask supplier how—but I will disregard these). </p>
<p>A first client need in software projects is to get ‘it’ built;
‘finished and working.’ This alone is already a cause of many a
conflict in software projects. I will show later how to get a much better
handle on this issue.</p>
<h4>people, get moving</h4>
<p>Another client need in software projects is to save money. At least, it
used to be in the past decades, when software automated a lot of mechanical,
brain‐dead labour, especially in office environments. Additionally,
looking at a software project in this way is very spreadsheet‐friendly.
The temptation of this should not be underestimated. </p>
<p>But time has moved on and just about all mechanical jobs have been rationalised
away. What remains is <strong>creating value</strong>. This is exactly what
<em>people</em> do: deal with situations with flexibility, provide
a human touch to communication, solve issues and create new ways to do things.
Machines and software do not stand a chance there. Over the years I have made
this value creation the core of my design praxis.</p>
<h4>intermezzo: what about value?</h4>
<p>Let’s take a short detour and see some examples of value creation.
We start with a plain project description:</p>
<p class="hang"><i>‘We need a new order‐taking system.’</i></p>
<p>Then we ask where the value is:</p>
<p class="hang"><i>‘We need a new order‐taking system, tightly
integrated with manufacturing and warehouse operations.’</i></p>
<p>No, that is not it. That is still a very mechanical description
of what needs to be achieved. Try again:</p>
<p class="hang"><i>‘We need a new order‐taking system that allows users
to unbureaucratically engage with any customer wish.’</i></p>
<p>There we have it: value. Feels really different than the previous two,
doesn’t it? Introducing software that realises this will be of clear
competitive advantage to this client.</p>
<p class="hang"><i>‘We need a new order‐taking system that allows users
to be order makers, instead of order takers.’</i></p>
<p>Another statement with value; not better, not worse, just different. This
demonstrates that defining value is a strategic choice for clients.</p>
<p>Flesh out the two statements above to three paragraphs, answering ‘what
is it we are making, who is it for and where is the value?’ and you have
what I call a vision.
And vision is exactly what I expect from management and leadership in a software
project.</p>
<h4>back on track</h4>
<p>Where were we? Ah, value is definitely a client need in a software project.
And by formulating that in a vision statement we have moved to the first thing
clients have to <em>offer.</em></p>
<p>We did already see that clients offer that software projects exists at
all. And therefore they have to offer funding, because projects without
funding turn out to be sad affairs, in my experience.</p>
<h3>tech</h3>
<p>The second world that we will take a look at is that of technology, i.e. the
in‑house <acronym>IT</acronym> department or the external suppliers.
All engineers, developers, technical architects, <acronym>DBA</acronym>s and
functional analysts are part of this world.</p>
<p>Cut to the bone, the sole reason these in‑house
<acronym>IT</acronym> departments and external suppliers exist is to
hoover up those software projects and budgets that clients have to offer. It
is their first, and prime, need. This is a marked difference with the world of
software products, where technology departments are
achievement‐focussed.</p>
<h4><acronym>XOR</acronym></h4>
<p>The second need the tech world has is that of clarity. From the
zero/one definition of a bit upwards, in black and white terms. What needs to
be built and when can we call it finished? This is compounded by the need of
the tech world to frame and communicate everything in technical terms.</p>
<p>As such, the tech world is completely at ease working from the statement
we have seen before:</p>
<p class="hang"><i>‘We need a new order‐taking system, tightly
integrated with manufacturing and warehouse operations.’</i></p>
<p>Given enough time and budget, they can bring this to a good end by
themselves. But they are completely lost with the value part in this
statement:</p>
<p class="hang"><i>‘We need a new order‐taking system that allows users
to unbureaucratically engage with any customer wish.’</i></p>
<p>Yes, the sales types of the tech world will nod understandingly when
clients express the value they need. But when the actual work starts, their
colleagues will hem and haw until the statement is reduced to something
like the first one, i.e. technically precise, but without value.</p>
<h4>truly, always</h4>
<p>What the tech world has to offer is the engineering and building of
software. <em>Everyone</em> knows that in order to get software, it needs to
get built, i.e. code developed. The brutal reality of software making is that
everything else I describe in this blog post is perceived by clients as
optional, even down to the proper engineering part: ‘just bang some code
together.’</p>
<p>The tech world expertly plays this ‘you need to get it built’
card. They play it to get (just about) all of the available budget, and to
bury deep under the ground anything they don’t ‘feel’
like doing.</p>
<h3>users</h3>
<p>The last world that we will take a look at is that of users. And here
the circle closes, because what <strong>users</strong> have to
<strong>offer</strong> is <strong>value creation</strong>. We can now
see what software is:</p>
<img src="http://mmiworks.net/pics/blog12/bus.png"
alt="a bus" width="249" height="82"/>
<p>It is a means of <em>value transport</em>, provided by the client and
built by technology. The software is there to meet its users, pick up
the value they create and bring it back to the client:</p>
<img src="http://mmiworks.net/pics/blog12/bus+users.png"
alt="a bus with passengers beside it" width="380" height="82"/>
<p>But to pick up that value, the users will have to get on the bus. Paying
them is not enough, neither is a direct order. These will make them
endure the software, but they will not even consider getting on the
value bus.</p>
<p>How do you entice users to get on the bus? You do it by <em>observing the
needs</em> of these users and addressing them in the software. What are these
user needs? Well, that is exactly the question the
<acronym>IT</acronym> industry has been struggling with for the last
50 years.</p>
<h4>Morse code</h4>
<p>What happens traditionally in software projects is that (indirectly) the
three worlds—client, tech and users—sit down to discuss what users
need. It is literally three different worlds meeting, three different
cultures, speaking three different languages:</p>
<img src="http://mmiworks.net/pics/blog12/intersect3.png"
alt="3 circles with a tiny intersection area between them"
width="380" height="357"/>
<p>You can see that the intersection of all three is very small. It has a name:
<em>discussing features</em>. Features, features, ever more features. A very
human phenomenon is feature hoarding. Just like kids and toys, there can never
be less features. No, that is a regression.</p>
<p> Everything gets phrased as a feature request—the only means of
communication available. Often users are asking that an existing feature gets
improved (e.g. finally made findable, or usable), but it gets phrased as an
additional feature.</p>
<h4>gimme some dough</h4>
<p>Features are a commodity, think
<a href="http://en.wikipedia.org/wiki/Staple_food">staple foods</a> like rice,
corn and wheat. Sure, not enough and users will starve. But increase supply beyond
<em>enough</em> and you have glut. In real life, people’s attention turns
to better food when they have enough. In the software world, the need for a
better meal is answered by a huge buffet of mediocre food.</p>
<p>The biggest mistake the software industry makes is listening to these
feature requests and supply what users <em>want</em>. This is the prime
reason supposedly tailor‐made project software ends up being the armpit
of usability. Remember, the goal was to find out what users <em>need</em>.
There is a solution for this, it is called usability.</p>
<h4>intermezzo: what about usability?</h4>
<p>Another detour. There are two definitions for the word usability that you
have to know:</p>
<ol>
<li>Measure of how usable, i.e. fit for use, something is. It is qualitative;
this makes the tech world nervous because there is no hard numbers.</li>
<li>A group of empirical professionals who measure usability and survey user
needs. Their general background is psychology. Tech‐splanation: they are
specialised in this type of hardware called humans.</li>
</ol>
<p>This is incredibly useful. Usability professionals can be engaged to
deliver an exact map of a software project users’ needs
<strong>and</strong> measure whether software is actually fit for use. The
effort and cost of this scales with the size of the project. In general it is
peanuts compared to what development hoovers up.</p>
<h4>back on track</h4>
<p>Where were we? Ah, knowing users’ needs is fully within reach, a
question of <em>just do it</em>. Now we need one more thing. We need to
connect the world of clients, technology and users; to translate between them
and hook up the needs and offers. There is a solution for that, it is
called interaction design.</p>
<p>That is what I do as interaction architect. It involves making the plan
for the bus. For clients I realise the value transfer; for tech I make clear
what needs to be built; for users I ensure their needs are met.</p>
<p>To show how this works I will now present my recommendations for software
projects, in nine easy steps:</p>
<h3 id="projstep1">1. you got to have a vision</h3>
<p>Before kicking off a project, even getting that budget, why not make it
crystal clear what value is going to be created and formulate a project
vision? I <a href="http://mmiworks.net/wedo/product.html">help my
customers</a> all the time to discuss, clarify, reach consensus and formulate
one; this fits nicely in a one‐day workshop.</p>
<p>It serves as a first feasibility check, getting a convincing vision
together. And it can be immediately used to ‘sell’ the project
internally and get a modest budget for the next steps. Costs involved?
One–two man‐days for the workshop.</p>
<h3 id="projstep2">2. start with user needs</h3>
<p>Right here, at the very beginning of the project, is the right moment to
get the user needs mapped out. These are already a useful foundation for
strategic platform—desktop, browser, tablet and/or smartphone?—and
architectural decisions. Why take these without knowing what
is needed?</p>
<p>Usability specialists survey and observe your project’s users and bring
back the facts. As mentioned, you are still not spending any serious
money at this point.</p>
<h3 id="projstep3">3. integrate usability + interaction</h3>
<p>Now is the time to integrate usability and interaction design with your
project. This does not happen by itself. The software industry has the
tendency to bolt on interaction design somewhere at the bottom of the
development pyramid and stick usability research in a drawer. Sorry, but that
is not going to help you.</p>
<p>Usability professionals are the only objective partners a client has for
knowing what users need and if the software is really <em>working</em>. The
interaction architect is the partner for <em>realising</em> your project
vision of value creation. Processes will have to change too; you cannot make
software like you did ‘last time’ when the results should
<em>really</em> not be like last time.</p>
<h3 id="projstep4">4. design it first</h3>
<p>With your vision, user needs and platform choices known, the
largest open question of the project—what do we need to build?—can
be answered. A first, rough design of the user interaction can be made by an
interaction architect (‑team for larger projects).</p>
<p>This will include a
<a href="http://mmiworks.net/wedo/design.html">solutions model</a>:
a large‐scale solution for realising that value creation, plus a design
strategy for working out the complete software in detail. This will take
the whole project out of the dark, into the light.</p>
<p>It is a good idea to have your prospective tech partners on board during
this design stage as discussion partners. Technical feasibility has a profound
impact on interaction design. And vice versa: interaction design has <em>the
same</em> profound impact on the architecture and design of back‑ends.</p>
<h3 id="projstep5">5. test it first</h3>
<p>Yes, not a line of code needs to be written to find out if the interaction
design is meeting your users’ needs—and by extension, if the goals
you set for value creation are fulfilled. A usability test with your users can
be performed with a paper prototype. I have seen many of these and they
simply work.</p>
<p>These tests are practical, quick and lightweight, involving six users,
maybe up to twelve if your user group is very heterogeneous. Anything beyond
that is project bloat, making it less agile. If you do insist on having it
tested on a real computer/tablet/mobile screen, then a prototype can be made.
This should take three days, not weeks or longer.</p>
<h3 id="projstep6">6. refine + test again</h3>
<p>The reason we made a rough design in step 4 and performed practical, lightweight
testing in step 5 is that we are going to iterate. From the analysis of the tests
the interaction architect keeps the parts of the design that work well and
redesigns the parts that performed badly.</p>
<p>These changes can be sweeping, because up to now relatively little time,
budget and commitment have been invested.</p>
<p>Then it is time for another round of usability testing and it will show
that giant step have been taken towards a fully working interaction design. If
still any <em>big</em> issues are found, then repeat this step of refinement
and test.</p>
<h3 id="projstep7">7. make interaction spec part of the contract</h3>
<p>You still have not spent any serious money up to now. You do have a
refined interaction design specification that shows what has to be built. It
has been tested to fulfil your users’ needs and to realise
your vision of value creation.</p>
<p>Now is the time to take this specification to your tech partners, the
in‑house <acronym>IT</acronym> department or the external
suppliers, and ask for a quote. It will be much easier to provide an
estimate on this basis and it will be more accurate. You will also be able to
define much better contractually what ‘finished and
working’ means.</p>
<h3 id="projstep8">8. test + test</h3>
<p>That’s two different tests. The first one is the usual, functional
testing of what is being built. Doing this against the interaction design
specification ensures that you get exactly what you expected. Passing these
test gives the tech partners an exact moment to call it finished. </p>
<p>The second type of testing is usability testing of alpha versions of the
built software. It checks for more subtle usability issues and validates the
overall interaction design. Again the interaction architect resolves the
issues and refines the design. The project impact of this is low, because all
the bigger issues were dealt with before development started.</p>
<h3 id="projstep9">9. <em>agile?</em> interaction architect is co‑owner</h3>
<p>Agile development was invented in + for the world of software
projects. Working agile does not change much of the eight steps above. In
<a href="#projstep4">step 4</a> one certainly needs to get to a solutions
model, to knock the project into shape.</p>
<p>More detailed interaction design can be postponed, to be delivered
just‐in‐time for the <em>start</em> of an implementation
sprint. Usability tests are performed on the evolving software, as described
in <a href="#projstep8">step 8</a>.</p>
<p>In the piecemeal work that agile entails, it is very easy to lose track
of a coherent user experience, one that meets your users’ needs. Making
the interaction architect software co‑owner in the agile process,
highly involved in planning of the next sprint and further sprints,
solves that.</p>
<h4>postscript</h4>
<p>And that’s it. I have shown that it is fully possible to set up
software projects where the needs of all the parties involved are met. The
clients’ need to get it built and for value creation; the tech
worlds’ need for clarity on what needs to be built and of when it can
be called finished.</p>
<p>Last, it is straightforward to find out what software users’ needs
are and to meet them through interaction design. At that point you can build
the value bus, one that users are pleased to take, to bring their
value home:</p>
<img class="cited" src="http://mmiworks.net/pics/blog12/onthebus.png"
alt="the passengers are on the bus" width="249" height="82"/>
<cite>bus symbol from
<a href="http://openclipart.org/detail/24071/bus-symbol-black-by-anonymous-24071">openclipart.org</a></cite>
Anonymoushttp://www.blogger.com/profile/13344735552467622739noreply@blogger.com0