Posts in Category “Work”
May 30, 2020
On Friday, my employer had a “learning day”. Among other things, I followed a typography video course called “The 33 Laws of Typography” by Jill Butler. I liked it a lot and I took notes so I could actually remember the conclusions of the course, so I’m publishing them here in the hopes that they will be useful for other people.
This will be long!
There are five categories for the 33 Laws of Typography:
- How to Format a Document
- How to Format Large Bodies of Text
- How to Format Small Blocks of Text
- How to Use Punctuation Properly
- How to Choose Typefaces
How to Format A Document
Distrust default software settings
In particular, Typeface, Type Size, Line Spacing, Margin Sizes, Text Alignment.
Ensure good contrast between text and background
To ensure text legibility. Reverse type (light text on dark background) is fine for small chunks of text, but have to be careful with thin strokes in the font (sans-serif tend to work better because of this, and extra letter spacing and line spacing).
Complex backgrounds can be almost impossible if there are different colours in it (impossible to have enough contrast with all parts of the background). In those cases, use a box with a single colour.
Avoid chartjunk and pagejunk
Chartjunk: excessive and unnecessary use of graphical elements in charts and graphs.
Pagejunk: excessive and unnecessary use of graphical elements on pages. Usually boxes, shadows, and rules.
Watch out for fancy, thick, and double rules in boxes. Also small margins in boxes… and pages.
Enforce consistent style within a document
Use software styles, or CSS on web.
Maintain a visual hierarchy
Document title, Level 1 Headings, Level 2 Headings, Body Text, Image Captions, Headers and Footers.
Plan which elements the document will contain so you can make design decisions about the hierarchy.
Group related page elements
Gestalt’s Law of Proximity, eg. having headings closer to the body text (or subheadings) than whatever is before them, so they are visually grouped with the text.
How to Format Large Bodies of Text
Set printed body text from 9 to 11 points
9pt to 11pt on print, 12px to 16px on web. Font size is measured from the top of the ascenders to the bottom of the descenders! That’s why different fonts look small or big in different fonts.
Set body text 2 to 3 alphabets wide
Too narrow is bad because all the eye jumps (and possibly jagged lines when left-aligned, or “rivers” when justified), too wide is bad because it’s hard to read long lines.
Should be 52-78 characters wide. For fancy typefaces or reverse type, 52 characters or a bit less is good. For justified text, better to use 78 characters or more.
Favour flush left, ragged right body text
The problem with justified is the potential “rivers” (horizontal gaps that sort of align). Shorter line lenghts are worse for justified text.
Flush right is ok for figure captions, attributions, and such.
Center for document titles, formal invitations, etc. It gives the document a conservative moods.
Separate sentences with one space, not two
Two spaces are a convention of the past, don’t use it. They produce big spaces that can be distracting.
Don’t allow less than 7 characters on a line
For example, at the end of paragraphs. Doesn’t look nice, and it wastes space. The goal is to keep visual balance. Ways to fix this:
- Widening the text block, to make the text reflow.
- Changing the font size.
- Edit the text itself (usually the best)
- Use a “soft return” (Shift-Enter) to force the end of a line.
- Use a non-breaking space so that some words cannot appear on different lines.
This is not just for body text, also for headings and such.
Avoid bad paragraph breaks
When paragraphs break in between pages, don’t leave a single line in either page (if it’s part of a bigger paragraph; single-line paragraphs are fine). Of course, titles that go with the paragraph should go together with the first line of that paragraph.
It creates visual imbalance and makes the point of the paragraph kind of moot because the text is not together. Solutions:
- Edit the text
- Tweak the “keep options” in the software you’re using (how many lines of text have to be kept together)
- Change the text box width / height
- Tweak the space that surrounds headings (if there are many)
- Add image or pull-quote
Avoid line-breaking hyphens
The automatic ones added by the software when a whole word doesn’t fit in the line. They are ugly and they break concentration and reading rhythm. They should be avoided.
If you must use them, don’t ever hyphenate any headings or proper names. Don’t allow more than 2 consecutively lines ending in hyphens in a paragraph. Don’t hyphenate URLs or email addresses. Don’t allow your software to make all the hyphenation decisions (you can control consecutive hyphens in a paragraph or turn them off).
Signal new paragraphs once, not twice
Don’t both indent the first line of each paragraph and add vertical space.
Never use spaces for the first line indent, always a setting (1-2 times as wide as the type size).
For vertical space, use space before or space after, not both. It should be 50-80% of the type size.
Break up large blocks of text
Too much of the same, full text page becomes dull and uninviting. Some possibilities:
- Drop Caps (drop together with the second/third lines of text) or Initial Caps (just big letter, same baseline as the first line of the paragraph).
- Rules: for headers, footers, and sometimes some headings.
- Pull quotes: highlighted quotes in a box, separate from the rest of the body text.
- Whitespace: big margins to lighten up the feeling of the page.
- Graphics. Only if they are good quality. They are not required.
Don’t add more than needed! Just enough to solve the problem.
How to Format Smaller Blocks of Text
Emphasize 10% or less of text
Emphasis should be limited so it stays effective. Both things like bold and such in body text, and font sizes and colours in business cards and such.
Avoid All Caps and Underlined Text
Limit their use to titles and headings. Underlines should be avoided, use italics instead. You can use rules for headings, never underline. Some good ways to emphasize text:
- Italics - should be used for book/film titles, too!
- Small Caps
- Different typeface
- Spacing - doesn’t work so well in body text, but it can be very effective in business cards, posters and others
- Size - same limitations as above
- Colour - be careful that the emphasis is not critical to understand the text
Choose one technique and use it throughout, don’t oversignal (use more than two or more techniques at the same time for the same words).
Set Acronyms and Initialisms in Small Caps
Acronyms are pronounced as words, initialisms are pronounced as each letter separately. These in all caps take over the document visually.
Small Caps (uppercase characters that are around x-height tall) look much better. A tiny bit of letter spacing makes acronyms look even better. Choose a type family that includes small caps typeface.
Hang punctuation in small chunks of text
Hang punctuation means that eg. the opening quote is outside of the left margin. Also final periods being outside of the right margin, when right-aligning text. Applies also to quotations, headlines with question marks at the end, etc.
In body text, punctuation is usually not hung, but it’s important in bigger font sizes and such.
Hang bullets and numbers in lists
It makes a difference when the items have more than one line. Numbers should be aligned in the “decimal point” (even if it’s not visible), ie. to the right.
Learn to use “tabs”: left-aligned, right-aligned, center-aligned, decimal-aligned.
Avoid Bad Line Breaks
There are two bad breaks: visual (visually disrupt the flow, eg. in left-aligned text, producing bad ragged edge) and contextual (sentences are broken so words that should appear together, don’t; it makes the reader go back and re-read).
Watch line breaks with URLs and email addresses, which should appear in full in one line whenever possible. How to fix?
- Edit the text
- Change text box width
- Change the size of the text
Use Symbols and Special Characters as Needed
Registered trademark, degrees, etc. Look for and use the proper one. Character map apps on desktop, character entities on web.
Not all fonts contain all these characters, so make sure that the font contains what you need, if you know you will need “special characters”.
Use Proportional Oldstyle Figures in Body Text
Numbers with digits that take different horizontal or vertical space. These are great for body text, but the “lining” (the other type, all digits are equally wide/tall and have the same baseline) is better for comparison and data tables and such.
There are tabular and proportional, too, so four types total (2x2 types):
- Oldstyle proportional: for body text
- Oldstyle tabular: for uppercase text
- Lining proportional: for fancy table data
- Lining tabular: for data tables
OpenType fonts are the ones that have all these combinations.
Adjust Leading and Kerning for Large Text
Leading: amount of vertical text from baseline to baseline (line spacing). Default is usually 20%.
Kerning: horizontal space between certain letter pairs (not the same as tracking/letter spacing).
Why do we need to adjust leading? For body text, default leading is usually fine. Large text usually needs less leading, and even less if there are few descenders!
Kerning is also usually fine for body text. In large sizes, sometimes kerning needs to be adjusted.
Verify Software Alignments Optically
Sometimes alignment is mathematically correct, but visually wrong, because some parts of the text, especially logos and such, are “visually lighter” so they should be taken as taking less space.
How to Use Punctuation Properly
Connect thoughts using em dashes
When to use em dashes when you don’t want a comma, but not sure what to use instead. They can be used to:
- Add emphasis
- Indicate long pauses and interruptions
- Indicate abrupt changes of thought
Full spaces between em dashes is wrong! But depending on the font (if the em dash touches or almost touches the letters) you might need to use a “thin space” (1/5 of an em wide). If you don’t have the option to add a thin space you can enter a space and use a smaller font.
Show Ranges Using en dashes
In between a hyphen and an em dash. It’s used for:
- Show ranges of time, duration, or distance
- Join words when at least one word is an open compound (New York-New Jersey Border)
- Join hyphenated compounds (post-Jacksonian–pre-Nixonian politics)
Don’t add full spaces between en dashes, but depending on the font, size, etc (if the en dash touches or almost touches the characters), you may need thin spaces.
Clarify and Improve Readability Using Hyphens
Their usage can be confusing. It should be used to:
- Improve readability and clarify meaning (five-dollar bills vs. five dollar bills)
- Joining a letter with a word
- When using the prefix “Re” to mean “repeating”, “again”
- Joining a prefix with a proper noun
- Joining a prefix and a root word with repeating characters: ultra-ambitious, non-native
- Joining two words that contain the same three characters in a row, eg. cross-section.
- Numbers between twenty-one and ninety-nine
- Phone numbers and social security numbers
- Joining two last names
It’s not the same as the minus sign! Don’t use hyphens for minus signs!
Designate Feet and Inches with Prime Symbols
Prime symbols are similar to but different from both curly quotes, and straight quotes. Straight quotes should never be used! When to use curly quotes:
- When quoting material (quotes inside quotes use the single quotes)
- Single closing quotes are the same apostrophes
Feet and single prime symbols, inches are double prime symbols. Math, music, linguistics and other fields also use prime symbols.
Replace Missing Characters with Apostrophes
When to use apostrophes:
- Gone Fishin’
- Bread ‘n’ Butter
- For decades, you say ’40s (missing “19”): the “40” doesn’t own anything
Careful with “Bread ‘n’ Butter”, because by default word processors will typeset the “n” in single quotes (the first one will be open, not closed).
How to Choose Typefaces
Limit typefaces to two per document
If you are not a professional, using more than that makes it too easy to become messy. One serif and one sans serif is a good place to start. Sameness competes, but differences highlight and contrast. If the difference is not big enough or doesn’t add anything, one typeface is much better.
Use typefaces that reinforce a document’s mood
It’s easy to feel overwhelmed by the choice of fonts, and you end up always choosing the same one. To help you choose, always think about the mood/personality of the document you’re creating.
Choose Serif or Sans Serif, based on aesthetics
For type size larger than 10 points, there’s no difference in readability between the two types. For smaller type sizes, sans serif have an edge, especially on computer screens (they are simpler).
For reversed text (white over black), medium-weight, slightly larger sans serif work best. You can use serif, but they have to have thick and uniform serifs: no “delicate” serifs!
So, in general, focus on the mood/personality and aesthetics first. Sans serif are a bit more modern and contemporary, and serif a bit more conservative and traditional.
This is it! I hope it was useful. I really recommend the course if you are interested in the topic: it has a bit more context and of course the visual examples and explanations that you lack in this summary.
Feb 15, 2012
This is the second part of my unit testing advice. See the first part on this blog.
If you need any introduction you should really read the first part. I’ll just present the other three ideas I wanted to cover.
Focusing on common cases
This consists of testing only/mostly common cases. These tests rarely fail and give a false sense of security. Thus, tests are better when they also include less common cases, as they’re much more likely to break inadvertently. Common cases not only break far less often, but will probably be caught reasonably fast once someone tries to use the buggy code, so testing them has comparatively less value than testing less common cases.
The best example I found was in the
wrap_stringtests. The relevant example was adding the string “A test of string wrapping…”, which wraps not to two lines, but three (the wrapping is done only on spaces, so “wrapping…” is taken as a single unit; in this sense, my test case could have been clearer and use a very long word, instead of a word followed by ellipsis). Most of the cases we’ll deal with will simply wrap a given word in two lines, but wrapping in three must work, too, and it’s much more likely to break if we decide to refactor or rewrite the code in that function, with the intention to keep the functionality intact.
See other examples of this in aa20bce (no tests with more than one consecutive newline, no tests with lines of only non-printable characters), b248b3f (no tests with just dots, no valid cases with more than one consecutive slash, no invalid cases with content other than slashes), 5e771ab (no directories or hidden files), f8ecac5 (invalid hex characters don’t fail, but produce strange behaviour instead; this test actually discovered a bug), 7856643 (broken escaped content) and 87e9f89 (trailing garbage).
Not trying to make the tests fail
This is related to the previous one, but the emphasis is on trying to choose tests that we think will fail (either now or in the future). My impression is that people often fail to do this because they are trying to prove that the code works, which misses the point of testing. The point is trying to prove the code doesn’t work. And hope that you fail at it, if you will.
The only example I could find was in the
strcasecmpendtests. Note how there’s a test that checks that the last three characters of string “abcDEf” (ie. “DEf”) is less than “deg” when compared case-insensitively. That’s almost pointless, because if we made that same comparison case-sensitively (in other words, if the “case” part of the function breaks) the test still passes! Thus it’s much better to compare the strings ”abcdef” and “Deg”.
Addendum: trying to cover all cases in the tests
There’s another problem I wanted to mention. I have seen several times before, although not in the Tor tests. The problem is making complicated tests that try to cover many/all cases. This seems to stem from the idea that having more test cases is good by itself, when actually more tests are only useful when they increase the chances to catch bugs. For example, if you write tests for a “sum” function and you’re already testing
[5, 6, 3, 7], it’s probably pointless to add a test for
[1, 4, 6, 5]. A test that would increase the chances of catching bugs would probably look more like
[-4, 0, 4, 5.6]or
So what’s wrong with having more tests than necessary? The problem is they make the test suite slower, harder to understand at a glance and harder to review. If they don’t contribute anything to the chance of catching bugs anyway, why pay that price? But the biggest problem is when we try to cover so many test cases than the code produces the test data. In this cases, we have all the above problems, plus that the test suite becomes almost as complex as production code. Such tests become much easier to introduce bugs in, harder to follow the flow of, etc. The tests are our safety net, so we should be fairly sure that they work as expected.
And that’s the end of the tips. I hope they were useful :-)
Feb 14, 2012
When reviewing tests written by other people I see patterns in the improvements I would make. As I realise that these “mistakes” are also made by experienced hackers, I thought it would be useful to write about them. The extra push to write about this now was having concrete examples from my recent involvement in Tor, that will hopefully illustrate these ideas.
These ideas are presented in no particular order. Each of them has a brief explanation, a concrete example from the Tor tests, and, if applicable, pointers to other commits that illustrate the same idea. Before you read on, let me explicitly acknowledge that (1) I know that many people know these principles, but writing about them is a nice reminder; and (2) I’m fully aware that sometimes I need that reminder, too.
Edit: see the second part of this blog.
Tests as spec
Tests are more useful if they can show how the code is supposed to behave, including safeguarding against future misunderstandings. Thus, it doesn’t matter if you know the current implementation will pass those tests or that those test cases won’t add more or different “edge” cases. If those test cases show better how the code behaves (and/or could catch errors if you rewrite the code from scratch with a different design), they’re good to have around.
I think the clearest example were the tests for the
eat_whitespace*functions. Two of those functions end in
_no_nl, and they only eat initial whitespace (except newlines). The other two functions eat initial whitespace, including newlines… but also eat comments. The tests from line 2280 on are clearly targeted at the second group, as they don’t really represent an interesting use case for the first. However, without those tests, a future maintainer could have thought that the
_no_nlfunctions were supposed to eat whitespace too, and break the code. That produces confusing errors and bugs, which in turn make people fear touching the code.
See other examples in commits b7b3b99 (escaped ‘%’, negative numbers, %i format string), 618836b (should an empty string be found at the beginning, or not found at all? does “\n” count as beginning of a line? can “\n” be found by itself? what about a string that expands more than one line? what about a line including the “\n”, with and without the haystack having the “\n” at the end?), 63b018ee (how are errors handled? what happens when a %s gets part of a number?), 2210f18 (is a newline only \r\n or \n, or any combination or \r and \n?) and 46bbf6c (check that all non-printable characters are escaped in octal, even if they were originally in hex; check that characters in octal/hex, when they’re printable, appear directly and not in octal).
Boundaries of different kinds are a typical source of bugs, and thus are among the best points of testing we have. It’s also good to test both sides of the boundaries, both as an example and because bugs can appear on both sides (and not necessarily at once!).
The best example are the tor_strtok_r_impl tests (a function that is supposed to be compatible with
strtok_r, that is, it chops a given string into “tokens”, separated by one of the given separator characters). In fact, these extra tests discovered an actual bug in the implementation (ie. an incompatibility with
strtok_r). Those extra tests asked a couple of interesting questions, including “when a string ends in the token separator, is there an empty token in the end?” in the “howdy!” example. This test can also be considered valuable as in “tests as spec”, if you consider that the answer to be above question is not obvious and both answers could be considered correct.
See other examples in commits 5740e0f (checking if
tor_snprintfcorrectly counts the number of bytes, as opposed the characters, when calculating if something can fit in a string; also note my embarrassing mistake of testing
snprintf, and not
tor_snprintf, later in the same commit), 46bbf6c (check that character 21 doesn’t make a difference, but 20 does) and 725d6ef (testing 129 is very good, but even better with 128—or, in this case, 7 and 8).
Testing implementation details
Testing implementation details tends to be a bad idea. You can usually argue you’re testing implementation details if you’re not getting the test information from the APIs provided by whatever you’re testing. For example, if you test some API that inserts data in a database by checking the database directly, or if you test the result of a method call was correct by checking the object’s internals or calling protected/private methods. There are two reasons why this is a bad idea: first, the more implementation details you tests depend on, the less implementation details you can change without breaking your tests; second, your tests are typically less readable because they’re cluttered with details, instead of meaningful code.
The only example I encountered of this in Tor were the compression tests. In this case it wasn’t a big deal, really, but I have seen this before in much worse situations and I feel this illustrates the point well enough. The problem with that deleted line is that it’s not clear what’s it’s purpose (it needs a comment), plus it uses a magic number, meaning if someone ever changes that number by mistake, it’s not obvious if the problem is the code or the test. Besides, we are already checking that the magic number is correct, by calling the
detect_compression_method. Thus, the deleted
memcmpdoesn’t add any value, and makes our tests harder to read. Verdict: delete!
I hope you liked the examples so far. My next post will contain the second half of the tips.
Jul 9, 2011
The DOM event “DOMNodeInserted”, very useful when you want to do some work based on new elements “appearing” on the page (as it’s more and more common).
As always, the code is on GitHub, so you can read it, fork it, make your own extension based on it or whatever you want.
Jan 5, 2011
It’s been more than two months since the GTAC and I never wrote anything about it in this blog, so I thought I’d write some words so I could cross it off my to-do list.
As you can imagine, the conference was great. It was my first big conference and my first time outside of Europe, so it was doubly exciting for me. And even though there were many interesting talks, meeting all that bunch of testing nerds was much better. It shows that Google really worked hard to make people socialise.
But let’s start from the beginning. Probably around a year ago now I had written a talk about testability that I had submitted to EuroSTAR 2010, but had been rejected. That had been my third rejection I believe, so I started losing hopes that I’d ever speak at an international conference. However, relatively shortly after being rejected Google announced this year’s event, and the theme was “Test to testability”, so I said “what the hell!”.
They said from the start that it would be invitation-only, meaning you had to apply even for simply attending. That was actually pretty cool, because the idea was that Google would choose the attendees, and once selected and notified, those attendees would _vote for each other’s talks _to decide what the program would be. It would also mean that attendees would be chosen because they had something interesting to add to the conference, not simply money to pay the registration fee.
And one day, right before leaving for a short vacation, I received the news that I had been chosen to attend. At that point, of course, I had no idea if I would actually talk, but just attending was awesome and I was really happy and a bit surprised (I was going to a conference! in India!). A couple of days later I received a lot of proposed talks to rate. That was pretty exciting, and seeing a lot of very interesting topics was kind of cool, because it was so promising, but also a bit discouraging, because I thought the chances of getting chosen were pretty low. Still I didn’t lose all hope, and when the deadline came, I was notified that I had been chosen to talk. At that point I was pretty surprised, but when I kept reading and saw that there were only 8 talks selected (+ 3 keynotes), then I was pretty shocked.
The rest of the story you don’t have to imagine, because in the typical Google fashion, all the conference material is available on the website (both videos and slides). As I imagine that the conference page link will break sooner or later, I’ll just give you the official GTAC 2010 YouTube playlist. My favourite talks were (in order of appearance):
Twist, A Next Generation Functional Testing Tool - really nice tool and very good demo, although not being open source and being for Eclipse was kind of a let down
The Future of Front-End Testing - kind of everything a professional QA Engineer should know about front-end testing, but it’s not always the case; I thought it was kind of basic, but it was a useful reminder and listening to Simon Stewart is just fun
Flexible Design? Testable Design? You Don’t Have To Choose! - great talk with unit testing tips/patterns; one of the nice things is that those patterns are not only for statically-typed languages
Crowd Source Testing, Mozilla Community Style - very nice talk about making the community help you testing complex products, with many examples and details
I guess I should also mention “Measuring and Monitoring Experience in Interactive Streaming Applications” and “Turning Quality on its Head”. The first, because I thought it was a cool story about how hard it is to find bugs that are important for users, but are vague and hard to reproduce. The second, mostly because of the tool that James shows off. You can see screenshots and an explanation of it from minute 52.
About my own talk, “Lessons Learned from Testability Failures”, I was really worried that I was going to freak out and block on stage. After all, I was used to talking in front of 5, 10, 20 or maybe 30 people. Speaking in front of around 100 and knowing that I was being recorded for YouTube (and that a lot of people interested in the subject would watch those videos) was quite scary in itself. And then there was the other factor: I usually speak to people who (theoretically) know less than me about that concrete subject, but it wasn’t like that at all in this case. However, people there were so cool and friendly that I felt less nervous than I usually feel. Watching the video, I do look nervous the first minutes, but after the introduction and such it felt really good. Kudos to the organisation and the attendees for being so open, cool and friendly. Meeting all that crowd was clearly the best of going to be conference.
All in all, it was a great experience and I made a lot of contacts and friends, and I’m looking forward to attending another similar conference (maybe next year’s GTAC?). We’ll see.
Oct 12, 2010
And this is the last past of the summary of “Storytelling for UX” (first part, second part). In this last part I’ll cover the tips to create stories. At the end I’ll do a mini-review of the book and will add some extra comments.
How to create a story_ _
Stories have four elements: audience, ingredients, structure and medium.
There are two important relationships in stories: story-audience and you-audience. About the first, you want to include details that fill the gap, and also stories are a good way to make the audience see a different perspective by feeling it. Finally, endings are important. They should be memorable and settled (“take them home”).
See checklist on p. 209.
Perspective. there isn’t a neutral POV in stories. Types of perspectives are realist (3rd person, “absent” author), confessional (focused on author experience) and impressionist (mixes descriptions of events with a strong structure). The last intends to spark ideas/actions and while they can have an ending, they might end with implicit question. An easy way to add perspective is letting the main character do the talking.
Characters. One of the reasons why UX stories are useful is because they add specificity and texture to the usually one-dimensional view of users. Also useful to highlight needs outside the mainstream. Tips to build characters: (1) choose (only) details that add meaning; (2) show, don’t tell (show in action instead of describing traits); (3) set up “hooks” that you can use later in the story; (4) leave room for imagination.
Context. Five types: physical (time, date, location, location scale), emotional (how characters feel), sensory (5 senses), historical (“when phones had dials”), memory (storyteller’s memory, flashbacks).
Imagery. Things that make us picture the story (example in p. 205). Don’t use too much!
Language. Tips: (a) speak in the language of the characters, (b) make the story active, (c) focus on telling the story, not describing, (d) don’t judge characters, context or events.
Structure is the framework/skeleton of the story. Plot is the arrangement of the events. Strong structures help the audience, the author and the story (p. 215). See types of stories on p. 216. “Checklist” for good structure and plot on p. 235.
Four big media: oral (mind the gap to written, p. 243), written (make the point explicit, keep it short, make use of cultural cues as in p. 253), visual (comics and storyboards work, see p. 258-260), multimedia/video.
See tips on how to integrate stories in reports on p. 265 and p. 266. See strong sides of different media on p. 272.
Mini-review and conclusions
I quite liked the book, although I admit that the last part (the one summarised in this post) was a bit disappointing. I guess it’s hard to give tips about something as complex as creating a story, in a book. The book has a very clear structure and it’s easy to follow and read, which helps in figuring out what to read, what to skim and what to leave for later.
Another thing that really struck me while reading the book (the second book I read following the tips from “How to Read a Book”) is how little I used to understand of the books I read. I now go through the book three times: one to get an idea of the structure and the most interesting parts, one to read the content, and one to review and make a summary. So even while I was reading it for the last time, I made sense of things that I hadn’t realised while reading the book (and that was after knowing the structure, knowing what to expect from each chapter, and having made some preliminary notes!). Not only that, but I also feel that I’m much more critical with what I read and I compare it much more with what I think myself.
If you aren’t doing it already, I strongly recommend that you give those tips a try…
Oct 11, 2010
This is the second (and longest) part of my summary of “Storytelling for UX” (see the first part). It will cover how to fit stories and storytelling into the UX design process.
There shouldn’t be “a storyteller” in the team, as many as possible should be familiar with the technique. Prototypes based on stories allow exploration of new ideas, esp. if they’re big changes.
There are several parts of the UX process were stories are useful:
Collecting input from users. You’re already hearing those stories. Do it consciously.
Exploring user research and other data. Summary of hard data.
Experimenting with design ideas. See stories that help launch a design discussion (type) and the role “spark new ideas”.
Testing designs. They can evaluate if you have stayed true to original needs and if they will work with real users.
Being in the user work environment helps noticing things people don’t mention. When you just arrive, everything is unfamiliar. Take notes then. If you can’t talk to your users, you can get some limited info from: search/server logs, customer service records, people who do training and sales demos, market research and satisfaction surveys.
Getting people in groups can help make people talk (build on each other). Also asking people to recall specific events is really useful.
Tip: be open to tangents, but don’t waste too much time in them if you don’t see value. Also, a user avoiding talking about what you want is information, too.
Tip: Use a structure for the interview (first closed questions, then open), see p. 82. Try to have the interview in the context the product will be used.
Characteristics of good stories:
Heard from more than one source
With action detail
Make user data easy to understand
Illustrate an aspect the UX team is interested in
Surprise or contradict common beliefs
They should help explain something about UX beyond data, bring data to life. They should also connect with other stories and resonate, leading to action.
Experimenting with design ideas
Three possible uses of stories: brainstorming, concept and specification. When no user research is available, you can brainstorm to create user stories. See a good technique/game for it on page 111.
When you do have user research, you can develop those stories. For that, some rules: (1) defer judgement, (2) encourage wild ideas and (3) build on the ideas of others. See adaptation of the game for this case, p. 118. Concept stories should include: (a) focus on activity set in a specific context, (b) description of motivations that trigger action, (c) describe the characters well enough to set them in context.
Specification stories are useful to summarise results. They are included in specs. They keep the real-world context available for reference.
Three uses of stories: create scenarios/tasks for usability testing, serve as guide for expert reviews, and quality testing.
If in usability testing you ask the user first what her interests are, you can turn that story into a usability test task.
Stories and personas from them are very useful to set a context for expert reviews. Give each expert a persona and make them try to complete a task from that persona POV.
[I didn’t really get the “quality testing” part, whatever that means, so I don’t have notes about it]
When communicating with people, stories get the audience attention, set context and inspire action.
Listening exercises make you understand your audience, and make them understand how diverse/similar they are.
There are three typical types of audiences:
Strategic leaders: generate and maintain a common vision (p. 143). Things that work for them: identify point of pain and offer a solution, identify gap in market and show how to fill, show new approach by reconfiguring common/existing components, and identify UX trends and show impact on business.
Managers: have a mission and have to make decisions (p. 146). Don’t have time to spare, prefer short meetings to brainstorming sessions. If you bring bad news, show why it’s important to care. Don’t go into much detail.
Technical experts: implement a vision (p. 149). Can be difficult to reach them with stories, esp. if not grounded in details. Tips: (a) use representative characters and situations and be ready to back up with hard data, (b) make the action of the story specific and tangible, (c) keep the story on track, (d) use technical terminology accurately.
And that was the end of this part of the summary. In the next and last post I’ll cover the tips about creating stories and will write some sort of mini-review and conclusions.
Oct 10, 2010
This is book is the first book chosen for Oslo’s UX book club. It was a quite interesting book about using stories and storytelling techniques in different steps of the User Experience design process. The following is the first part of my (long) summary of the book. The summary is mostly intended to remind me things I read, but probably/hopefully it will be interesting and useful to others. As the book is more or less divided in four parts (introduction, listening, how to fit stories in the process and how to create a story), I’ll cover the introduction and the notes on listening in this post, and will leave the other two parts to other posts. Edit: see parts two and three.
Introduction (chapters 1-2)
Stories help keeping people at the center (p. 2). There are different types of stories (p. 5):
Those that describe context/situation: describe the world today. Not only sequence of events, but also reasons and motivations.
Those that illustrate problems: show a problem that a new product or design change can fix. They should describe it in a way that opens the door for brainstorming.
Those that help launch a design discussion: starting point for a brainstorming session. Enough detail to make sense but leave room for the imagination.
Those that explore a design concept: explain/explore idea or concept and its implications for the experience. Helps shape the design by showing it in action.
Those that prescribe the result of a new design: describe the world as it will be in more detail. Similar to the 1st, but describe a user experience that doesn’t exist yet.
Interesting quote in page 10, with the message “until you hear a story, you can’t understand the experience”.
Stories are interactive, change with the audience (p. 14). They also not only describe actions, but add context and why (motivation). There is a fine line with how many detail to include in motivation, because of shared cultural understanding and other things (p. 17, 19).
Stories have different roles:
Explain: give context and sensory experience, not just events. This is different from use-cases.
Engage the imagination: surpass linear logic and evoke new ideas.
Spark new ideas: as we fill in the gaps, we can hint details but let people come up with their own ideas.
Create a shared understanding.
In any case, stories are not “made up”: they’re based on data.
Listening (chapter 3)
Really listening to users (e.g. in interviews and such) gives you access to a lot of info you can’t get anywhere else. Open questions are very important for this. Giving time to answer sometimes gives people time for second thoughts (not just what they think you want to hear), which has more value than the first reply. Also, pay attention to the context, people forget to mention “obvious” (for them) everyday facts.
Practising active listening is very important, see the following links:
And that’s it for the first part. Stay tuned for the rest of the summary.
Aug 10, 2010
This post is probably not about what you’re thinking. It’s actually about automated testing.
Different stuff I’ve been reading or otherwise been exposed to in the last weeks has made me reach a sort of funny comparison: code is (or can be) like science. You come up with some “theory” (your code) that explains something (solves a problem)… and you make sure you can measure it and test it for people to believe your theory and build on top of it.
I mean, something claiming to be science that can’t be easily measured, compared or peer-reviewed would be ridiculous. Scientists wouldn’t believe in it and would certainly not build anything on top of it because the foundation is not reliable.
I claim that software should be the same way, and thus it’s ridiculous to trust software that doesn’t have a good test suite, or even worse, that may not even be particularly testable. Trusting software without a test suite is not that different from taking the word of the developer that it “works on my machine”. Scientists would call untested science pseudo-science, so I am tempted to call code without tests pseudo-code.
Don’t get me wrong: sure you can test by hand, and hand-made tests are useful and necessary, but that only proves that the exact code you tested, without any changes, works as expected. But you know what? Software changes all the time, so that’s not a great help. If you don’t have a way to quickly and reliably measure how your code behaves, every time you make a change you are taking a leap of faith. And the more leaps of faith you take, the less credible your code is.
Jul 5, 2010
These are interesting times in the browser world: not only there are more browsers than ever, but now even Internet Explorer is starting to become competitive again, so in a year or two it might not even be safe to assume that every other browser is better. Go figure.
So anyway, recently Opera released 10.60, which is awesome news because finally Linux has a modern stable release, because of the amount of new eye candy in the UI, the new supported web standards (like Geolocation or WebM video, yay!) and… because of the amazing speed (“much faster than a potato”).
On Saturday, DailyTech published an article comparing the speed of several browsers, Opera 10.60 included. Obviously the conclusion was that Opera is the fastest (I wouldn’t link to that article from this post if it wasn’t the case, would I? :-P), and shortly after reading that, I came across this hilarious video that sort of follows up on that:
I mean, the video even mentions Opera Link, I have to like it :-P (although yeah, the claim is not correct, Chrome does have something similar). My favourite quotes are:
“You promised innovation, but look at Opera!”
“Maybe Opera is hiring”
And the second reminded me that yes, we are hiring!
Jun 19, 2010
Google Test Automation Conference. In India. Sounds great, doesn’t it? That’s what I thought too, so I applied. For that, though, I had to shoot not only one, but two videos: one explaining the full-length talk I wanted to present, and a video of a lightning talk. As both of them were related to talks, I figured they’d be much better off having the slides on the video when they were referenced. That way the videos would be easier to follow and wouldn’t be just a boring static shot.
But that meant I had to edit video. Which I had never done before. And I figured it wouldn’t be trivial if I only wanted to use Free Software tools under Linux. I was partly wrong, because after looking around a bit I found OpenShot, which I found pleasant enough to use (at least for my very basic, very limited needs). However, the final footage I used made OpenShot export corrupted videos. I know it was something specific to that source video (a MOV format, H.264 codec, EPICly HD resolution (1920x1080) video) because I had tried to do exactly the same things with earlier, lower-resolution, MPEG-format takes, and it had worked like a charm.
In any case, I was sort of fucked because I couldn’t get the final edited video out, so I had to resize it and change the format somehow. I won’t list here everything I tried (that includes trying to download and use several programs on Windows, as well as using mencoder on Linux), but after a very long and frustrating process, only ffmpeg did the trick for me. My first attempt with ffmpeg did export the video, but with awful quality. After looking around a bit, I found what worked for me:
ffmpeg -i original.mov -s hd720 -b 3200k resized.mpeg
The trick to get a decent result was forcing the bitrate (“-b” option), which will hopefully help someone in need. Meanwhile, I’m going to stop typing so I can go back to crossing my fingers to get picked for GTAC ;-)
Mar 22, 2010
For some time now I had been frustrated by the tools to manage APT repositories. The only ones I knew of either covered too little (only adding/removing packages from a repository and such, like reprepro) or were way too complex (like the official tools used by Debian itself). Maybe/probably I’m a moron and I just didn’t know of some tool that would solve all my problems, but now it’s kind of late ;-) And before you say it, no, Launchpad is not what I was looking for as far as I understand it.
So I started to work on my own suite of tools for it, and recently I decided to release what I’ve done so far. It’s by no means complete, but it’s very useful for me and I thought it would be useful for others. And, with a bit of luck, someone will help me improving it.
So what is it? Arepa (it stands for “Apt REPository Assistant”, but obviously I called it like that after the yummy Venezuelan sandwiches) is a suite of tools that allow you to manage an APT repository. It contains two command-line tools and a web interface, and its main features are:
Manages the whole process after a package arrives to the upload queue: from approving it to re-building from source to signing the final repository.
It allows you to “approve” source packages uploaded to some “incoming” directory, via a web interface.
It only accepts source packages, and those are re-compiled automatically in the configured autobuilders. It can even “cross-compile” for other distributions (treated like binNMUs).
The approval via some web interface was actually sort of the driving force for the project. One of my pet peeves was that there wasn’t an easy way to have an upload queue and easily approve/reject packages with the tools I knew. From what I had seen, the tools were either for “single person” repositories (no approval needed because the package author is the owner of the repository) or full-blown distribution-size tools like dak and such. My use-case, however, is the following:
You have an installation of Arepa for an entire organisation (say, a whole company or a big department).
People inside that organisation upload packages to the upload queue (possibly using dput; the point is, the end up in some directory in the machine hosting Arepa).
Someone (or a small group of people) are the “masters” of the repository, and they’ll have access to the web interface. From time to time they check the web UI, and they’ll approve (or not) the incoming source packages.
If they’re approved, the source will be added to the repository and it’ll be scheduled for compilation in the appropriate combination(s) of architectures and distributions.
A cronjob compiles pending packages every hour; when the compilation is successful, they’re added to the repository.
At this point, the repository hosted by the Arepa installation has the new packages, but you probably want to serve the repository from a different machine. If that’s the case, Arepa can sync the repository to your production machine with a simple command (“arepa sync”).
I imagine that a lot of people have the same need, so I uploaded all the code to CPAN (you can see it with the rest of the contributions by Opera Software). Sadly there’s a silly bug in the released code (I wanted to release ASAP to be able to focus on other things, and I ended up rushing the release), but it has both a workaround and a patch. So, please give it a try if you’re interested and tell me if you would like to contribute. I haven’t released the code in GitHub or similar yet, but I’ll probably do if there’s interest.
Sep 13, 2009
I spent the whole last week (or this week; after all it’s Sunday… and Sunday is obviously the last day of the week, not the first, right?) in Linköping, Sweden. The idea was repeating some Debian course I gave here in Oslo, giving two more talks about automated testing since I was there anyway, and attend two more talks. It was lots of fun, partly thanks to my “host” (thanks Gerald!), and surprisingly I found a bunch of things that seemed plain weird to me… or at least quite different from Oslo.
The talks themselves went pretty good I think, although I’d have preferred more people attending. I guess it was normal that there were less people than I’m used to, since the Linköping office is much smaller. But anyway. The Debian course went quite well and some people got started packaging stuff almost right away. The other talks were an introduction to automated testing (advocacy and arguments for it, advice, basic examples and small rant about a different kind of QA), which went ok, and an entry-level talk about unit testing in Python (thanks Ask and Batiste for the information and reviewing the slides!), which went very well. I’ll try to get the slides for all the talks available somewhere.
About the city itself, it’s a charming little part of Sweden where:
Restaurants have insanely different prices for food whether it’s for lunch or dinner. Typical prices for lunch are 80 SEK (around 8 EUR) and typical prices for dinner are around 250 SEK just the main course!
Restaurants usually serve some Swedish dish for lunch… and I mean every restaurant, meaning all the Greek, Vietnamese, etc. Considering “real” Swedish restaurants are very expensive, you usually go to those foreign cuisine ones when you actually want to eat Swedish food.
Restaurants typically have some salad (that you have to take yourself) while you wait for the food… and some coffee, tea and cookies (that obviously you have to take yourself) for the end.
Related to this, restaurants are usually very self-service. I thought service in Norway sucked, but boy was I wrong, at least there is some service. And: there were typically long but pretty-fast-moving queues, and there was this one place where you didn’t even get the food on the table after ordering at the bar; instead, you were given some gadget with some wireless receiver, and when your food was ready it’d beep so you knew you had to go to some special place and fetch your food. Is it really cheaper maintaining some gadgets than hiring a waiter? I guess so.
The restrictions on the amount of alcohol that can be bought outside the special Government booze stores are even harder than in Norway. You can only buy booze with up to 3.5% alcohol outside “Systembolaget”. Now that is sad. And I was complaining about Norway’s 5%.
Partly because of that (I assume/hope) the Swedish “cider” you get in Sweden is even sweeter and worse and the Swedish cider you get in Norway.
We went to this nice student pub… which was literally for students. They actually checked your student id, but each student could bring one non-student along. Once you were “identified” as a non-student-coming-with-a-student, you’d get a stamp on your hand so you wouldn’t have to bring along the student when you ordered again. Also, the place was so very slow it was almost funny. One of the good sides was that they had what I thought it was the only decent Swedish cider… but after checking just now, it seems it’s actually American. Bummer. And the name of it was funny too: “Hardcore Cider”.
Right before leaving the office on Friday there was a small gathering in the canteen (the “Friday Beer”), where they had a Dreamcast with one of the most awesome games I’ve seen in a long while: The Typing of the Dead, a version of The House of the Dead 2 in which you kill the zombies by typing words that appear on the screen, instead of aiming and shooting with a gun:
Jul 19, 2009
Those who know me professionally know that I care a lot about software quality assurance. I think it’s a mostly misunderstood field, and generally “the world” would be better off with more QA (and/or better QA). Of course, I’m always looking for more arguments to support my view :-D and the last one I found came from a very interesting blog post, Plane Crashes, Software Failures, and other Human Errors. This post explains how mistakes are made in the aviation and healthcare industries, and claims something that sounds shocking but actually makes quite a bit of sense: “errors occur most often when a senior, experienced person is performing”. The reason why it doesn’t happen as often when the less experience person is performing (again according to the blog post): “because it means the second pilot isn’t going to be afraid to speak up”.
That got me thinking. No matter how expert one person is, he can’t take all the right decisions without help and feedback: a second opinion is always useful and can save the team from embarrassing (or, in some cases, fatal) consequences. A second opinion can give perspective or aspects not thought of by the first person.
If you apply this to software development, I can’t help thinking that one of the roles of QA fulfils this need: being experts in the field that provide second opinions and critiques on anything the team decides or produces. And they shouldn’t feel afraid to speak up because… well, it’s their job after all. And while yes, fellow developers could serve as “second opinion” too, having a more or less formal position for a “Quality Assurance Engineer” is helpful for a variety of reasons. First, as I said the chances of being afraid to speak up are much lower, because it’s their job. Second, not producing the result themselves gives some perspective that people having to fight with everyday details can have, but usually don’t; at least not as much. And last but probably important, it’s their job so they can focus on it and they don’t stop doing it because “they have deliveries soon” or because “they don’t have time”.
Finally, there is another blog post, linked from the above, that also supports my vision of QA: Toyota “Stop the Line” mentality. But this one is about processes and taking a step back when something is wrong, trying to find the root cause instead of an immediate solution. Enjoy the blog posts :-)
Jul 1, 2009
The initial idea of the loanmeter widget was to show where in the world Kiva was offering loans. However, as I used the widget myself, I realised that the location in the world was less important for me, and I was more interested in knowing what the person was going to use the money for. So, I added some options to filter by “sector” and I figured that having some graphs comparing how much money was requested and already funded, for each sector, would be a very quick and visual way to get the information I wanted. I started playing with flot, and I have to say that except for a couple of relatively minor problems, it was quite easy to use. I don’t have screenshots showing the graphs, but feel free to try the widget itself and have a look (hint: you have two buttons at the bottom right corner to switch between “map view” and “graph view”).
The other widget I have been working on is a monitor widget for projects in CruiseControl.rb (a really simple and neat continuous integration server we use at Opera). More than one year ago, my colleague Nico had written a very quick & dirty widget for monitoring the result of the test runs of the My Opera functional testsuite. There were a couple of things I wanted to change, and I also wanted to monitor other projects, so I figured that I’d rewrite the widget to have a more maintainable codebase and then make it generic, so you could configure which CC.rb installation and which project to monitor. I’m moderately happy with the result of the refactoring, and happy enough with the final result. I know it has several issues, and I expect that once anyone outside our team starts using it, there will be things to improve and fix :-) If you use CruiseControl.rb, give it a try!
Jun 28, 2009
I have been using Perl for many years, but I had never uploaded anything to CPAN. That’s unfortunate, because I’ve probably written several programs or modules that could have been useful for other people. The point is, now I have. Not only that, but it was code I wrote at work, so if I’m not mistaken these are my first contributions to free software from Opera. Yay me!
The two modules I’ve released so far are:
Parse::Debian::PackageDesc, a module for parsing both
.changesfiles from Debian. This is actually a support module for something bigger that I hope I’ll release soon-ish.
As I feel that Migraine could be useful to a lot of people, but it’s easy to misunderstand what it really does (unless you already know Rails migrations of course), I’ll elaborate a bit. Imagine that you are developing some application that uses a database. You design the schema, write some SQL file with it, and everybody creates their own databases from that file. Now, as your application evolves, your schema will evolve too. What do you do now to update all databases (every developer installation, testing installations, and don’t forget the production database)? One painful way to do it could be documenting which SQL statements you have to execute in order to have the latest version of the schema, and expect people to apply copying-and-pasting from the documentation. However, it’s messy, confusing, and it needs someone to know both which databases to update and when.
Migraine offers a simpler, more reliable way to keep all your databases up to date. Basically, you write all your changes (“migrations”) in some files in a directory, following a simple version number naming convention (e.g.
002-change_passwd_field_type.sql), and migraine will allow you to keep your databases up to date. In the simplest, most common case, you call migraine with a configuration file specifying which database to upgrade, and it will figure out which migrations are pending to apply, if any, and apply them. The system currently only supports raw SQL, but it should be easy to extend with other types.
In principle, you shouldn’t need to write any Perl code to use migraine (it has a Perl module that you can use to integrate with your Perl programs if you like, but also a command-line tool), so you can use it even in non-Perl projects. Of course, some modern ORMs have their own database migration system, but very often you have to maintain legacy code that doesn’t use any fancy ORM, or you don’t like the migration system provided by the ORM, or you prefer keeping a single system for schema and data migrations… I think in those cases Migraine can help a lot reducing chaos and keeping things under control. Try it out and tell me what you think
In a couple of days I’ll blog again about other contributions to free software I’ve made lately, but this time in the form of Opera widgets…
Jun 21, 2009
So we finally managed to get some public release of Opera Unite out of the door. That was a really good thing, first because it’s a very cool idea and we had to let others play with it and make it evolve, and second because it was painful keeping a secret for so long ;-)
In case you have been hiding under a rock these days and you don’t know what I’m talking about: Opera Unite is the latest crazy idea from Opera Software. Basically, embedding a web server inside the web browser, so that people can be more than spectators on the web, share their data without having to upload to third party services, and generally change the way they interact with the web. The cool thing is that the system is not limited to sharing files or whatever, you can actually program your own Opera Unite services to do pretty much anything you want (check the documentation in Dev Opera if you’re a developer). However, do note that this is just a Labs release, that is, just a preview of relatively immature software. For a more complete introduction, go to the Labs blog post introducing Opera Unite.
Opera created quite a bit of hype before the release, which seemed to work pretty well. In particular, the teasing in the HTML comments of the preview URL (http://opera.com/freedom), which were being updated every day by adding some more words, was brilliant. There has been a lot of press coverage of Opera Unite this week, and even some Russian fella created the website unitehowto.com the same day Unite was released, and he wrote (collected?) a bunch of information, articles and tutorials about Opera Unite.
I have to say that, although there has been some quite challenging times while developing Opera Unite (it’s a quite ambitious project that involves several departments with massively different backgrounds and values, what did you expect?), I’m quite happy with the result and I think we have made, in general, a good job. As I said, this is just a very rough version, and there’s a lot of work left to do, but I’m sure it will improve a lot before we release the final version. That said, I’m sure that the most exciting things about Unite will, without doubt, start happening once people start writing interesting services, changing the way we see Opera Unite and the way we see the web. I’m so eager to see what people are going to build with this…
Jun 1, 2009
I haven’t written in some time, I know. I haven’t done much worth blogging about. Just a new release of the Kiva World Loanmeter widget, and also a couple of things at work that I’ll be releasing soon (including a small tool for managing database changes and some Perl module to parse Debian
However, recently I watched a really funny and interesting talk at TED, Are we in control of our own decisions?, by Dan Ariely. In the talk he mentions his book, Predictably Irrational, which funnily enough a friend had already mentioned to me.
Well, I just finished the book and I have to say it was very interesting and eye-opening. It’s interesting how it shows our minds are biased for certain kinds of decisions or behaviour, even though they are often not the best for us. Some of the experiments are truly brilliant and they show totally unexpected (at least before starting reading the book ;-P) outcomes. One of the experiments that got me thinking was this:
> > Research on stereotypes shows […] that stereotyped people themselves react differently when they are aware of the label that they are forced to wear […] One stereotype of Asian-Americans, for instance, is that they are especially gifted in mathematics and science. A common stereotype of females is that they are weak in mathematics […] In a remarkable experiment, […] asked Asian-American women to take an objective math exam. But first they divided the women into two groups. The women in one group were asked questions related to their gender […] The women in the second group were asked questions related to their race […] The performance of the two groups differed in a way that matched the stereotypes of both women and Asian-Americans. Those who had been reminded that they were women performed worse than those who had been reminded that they were Asian-American. > >
I can’t stop thinking about the implications this has to working conditions and productivity in different countries, and also to project management.
May 10, 2009
I’ve been working on something lately that I hope I will publish sometime next month: it’s a set of tools to manage an APT package repository. The idea is that, given an upload queue (you can set it up as an anonymous FTP, or some directory accessible via SSH/SCP, or whatever floats your boat in your setup and team), you’ll have a web interface to approve those packages, a set of integrated autobuilders building the approved packages in whatever combination of architectures and distributions you want, and all that integrated with reprepro to keep your repository updated. I’ll write more about it when I have released something.
The point now is that, while working on it, I needed some module to parse command-line options and “subcommands” (like
svn update, etc.). As it’s written in Perl, I had a look at CPAN to see if I could see anything. The most promising module was App::Rad, but it lacked a couple of things that were very important for me: my idea was “declaring” all the possible commands and options and have the module do all the work for me (generating the help pages and the default
--helpimplementation, generate the
program help subcommandand so on).
App::Raddidn’t have that, and it didn’t seem to me like that was the direction they wanted to go to with the module. But I figured I’d drop the author an e-mail anyway and see if he liked the idea so I could start adding support for all that…
And boy was that a good idea. He replied a couple of days later, and said that they had liked the idea so much that they had implemented it already (that’s why he took a couple of days to reply), and he sent me an example of the new syntax they had introduced and asked if that was what I was thinking. And not only that, but they added me to the list of contributors just for giving the idea! That completely made my day, free software rocks!
Apr 28, 2009
I have to note here that I’m very proud of being part of Opera Link, which is consistently mentioned in the list of innovations.
Happy Birthday Opera!
Feb 26, 2009
About two weeks ago I wrote about Kiva, a cool website that allows people to make microloans. Almost one month ago they had started a developer site, including an easy to use API to access the data (loans, borrowers, lenders, etc).
I couldn’t resist the temptation to have a look at the documentation and start thinking about some application to use it. Soon after I started reading I came up with the idea of writing an Opera widget. There were a couple of reasons for that:
I had never written a widget, so it sounded like a good excuse to learn how to write them.
A widget in http://widgets.opera.com had more possibilities of actually being used than a random pet project of mine lying in some obscure repository of some obscure version control system (well, actually I ended up using Git for it, so it’s not that obscure in some sense; but you get the point).
Finally, for Git, I had a look at the screencasts hosted in GitCasts. I already new some basic Git things, but I think I started to feel more comfortable with it after watching a couple of those videos. Still, too many references to the obscure objects and SHA names and whatever, but clear enough to understand your way around it.
In short, I have to say that creating the widget was easy enough, and it was lots of fun to write it. I had some frustrations debugging it, but things worked fairly well in general. When I finished it, I uploaded to widgets.opera.com and after a couple of days it was already approved and public for everyone.
Feb 9, 2009
UPDATE: Bubug hasn’t been maintained for a long time and is now deprecated, sorry. The closest equivalent I have to a TODO application is Wiki-toki, my personal Wiki program.
I have been quite frustrated by TODO applications for some months now. They’re usually either too simple, or almost too complex and without features that I think are really valuable. In particular, there are two things that I don’t remember having seen in any TODO application:
Possibility to “postpone” a task, so it doesn’t appear in the main view for a defined time.
Possibility to associate a task to a “person to nag”.
When you have a lot of small tasks to do, and they are not the kind of things you put in a BTS (say, stuff that you have to do that is not really connected to some project’s code) I think these two features are really useful, and I was surprised that no applications I saw seemed to have those. I mean, don’t people have the same problems as me?
That’s why, as I had mentioned, I started writing my own TODO application: I’d have what I wanted, and I’d learn a thing or two about Merb, DataMapper and jQuery. The application has several design limitations that I used to simplify things, like not having any notion of users (single user app without authentication) or supporting only a “title” for the tasks, without any longer description. It isn’t something I really plan to publish for other people to use (I mean, the code is in my Darcs repo, I’m just not going to make a project page for it or anything like that), so I don’t really care how much it fits other people’s needs :-)
Dec 17, 2008
That’s the title of a really good book by Scott Berkun, the fella that was project manager for Internet Explorer when it could still be called a browser ;-) The Myths of Innovation is very easy to read, funny and has some food for thought. It dissects a bunch of myths about innovation and innovators, points out typical difficulties and dangers that innovators face, and analyses why these myths are common, why people like them, and why they are so handy to refer to the history and reality of innovation, which is of course much more complex.
One chapter that made me think a lot was chapter 7: “Your boss knows more about innovation than you”. It explores the relation between (traditional) management and innovation, and claims that managers can work against innovation if they just try to increase efficiency and keep things under control. In that sense, quality assurance engineers can be like those project managers, so I wondered a lot about my role and my duties with regards to innovation. On the one hand, you do have to control things that are being done and be conservative to a certain extent. On the other hand, innovation is such an important part of an IT company (particularly if it’s Internet-related) that you really don’t want to risk blocking or stifling it.
Fortunately, it also explains how to keep the workplace open to innovation, including things like having toys and “funny” things at the office. It turns out that they’re not there to spoil the employees, but to provide an environment where people feel free to “think different” and are not afraid of new ideas or to say what they think.
All in all, I think it’s a great book. Recommended!
Dec 14, 2008
I never liked Opera Widgets too much. I tried them a couple of years ago, but I never saw the point. I even tried the games, but they performed so ridiculously poorly that I just gave up. What did I need them for?
Around one year ago, however, I found the first useful widget, a kind of simple “monitor” for the Continuous Integration server run for some project. It was really simple and actually useful (basically, a big window that is either green or red). Shortly after, someone pointed me at a “random lolcat” widget (best widget ever, I say; unfortunately is not public), so I started to wonder if I was wrong and widgets were maybe useful after all.
Since then, I have found another widget that I find very handy, the Twitter widget, and I even realised that the performance problems were something of the past, so I could consider trying a couple of games. And, alas, it turns out that there are at least two games worth trying: Bubbles and my favourite, Ninja Ropes Extreme.
So give them a try, you might be surprised :-)
Nov 28, 2008
After a couple of (unrelated) recent events, I remembered that some/most people use some desktop “word processor” for writing and maintaining documentation. After years of working with Wikis for virtually all documentation, I have to say that I don’t understand why people still use those dinosaurs. Using a word processor for documentation feels so nineties.
When working in technical teams, I think the advantages of the Wikis are amazing:
You know you’re always reading/modifying the latest version. Uploading to a central server or a shared folder, although theoretically possible (and I’m sure some people do), I don’t think it works as well.
You can link all content to any other content (and if you keep all your documentation in the same Wiki, you can link to other project documentation or general company/team guidelines or conventions, for example).
You can keep bits of documentation that don’t fit in a standalone “document”, like collections of small tips, lists of things to take into account when you do this or that, checklists, configuration/code snippets and examples, journals, etc. And of course link all that to any other part of the documentation, as stated above.
You think “globally”, in terms of the content, not in terms of “documents” that are (usually artificially) independent from each other. Also, it’s mentally cheaper to browse through wiki pages than it is to browse word processor documents, so the documentation is more visible and more used.
You focus on content, not on formatting or the way things are presented. It’s also easier to keep the same consistent look and feel for all your documentation, if you wanted to change it.
As you don’t have “documents”, just “documentation”, people feel free to edit and update it whenever is necessary, instead of feeling the need to ask the “author” of each document.
You don’t need any special program that might not be available in all platforms, or at least not interpret the document in exactly the same way. It’s also easier to access it from other computers.
Documents don’t get lost or become obsolete because of the format.
You usually get revision control for free (revision control that makes it trivial to see the whole change history for the documentation, review which exact changes some person has made in a given moment, etc). And if you’re using a Wiki that doesn’t support version control, you should use a different Wiki
Of course, I’m not saying Wikis are the perfect solution, let alone independently of the team, company, project and context you’re using them in, but I think in general they are quite superior as technical documentation repository for a software development team.
Nov 16, 2008
I have to say I’m impressed with Opera Mini. It’s a very good product that not only is innovative, but also is damn hard to get working decently in a plethora of ill-designed, ill-implemented, crashing-and-burning-at-any-error, incompatible phones. But somehow these guys bring the Internet to everyone that has a mobile phone that supports Java (a pretty low requirement these days)… and that lives in a country where mobile phone operators don’t charge your ass for connecting to the Internet of course (and then again, Opera Mini heavily compresses the pages so you only download a fraction of the original).
And the experience, taking into account the limited interface, is pretty good. And they add features and improvements in every release (namely, they brought back “skins”, added notes to the list of supported Link data types, and probably other things I haven’t noticed). What else can I say?
The other day I wanted to go and buy some board game. I had gone to BoardGameGeek (awesome website BTW) and had made a list of the games that looked interesting. So I go to the shop, and of course most of them weren’t there… but there was some other game that looked interesting but I hadn’t seen before: Primordial Soup. Having Opera Mini in my phone, I could very easily check the rating and some basic information for that game, which helped me decide if I should buy it. Not only that, but thanks to Link I had the list of games I wanted to buy in my bookmarks (I had added them from my Desktop computer), so I could even compare the ratings for that game and the ones I wanted to buy to start with. How awesome is that?
Go Opera Mini team!
Oct 21, 2008
I admit it. I’m a terrible developer. I write code, sometimes even write tests.
But. I. don’t. test. my. programs.
By hand, that is. And sometimes (usually) the coverage is not enough, and I end up making embarrassing mistakes. It usually happens outside of work, although at work I also have my share. The last one was with the Debian package
dhelp, where trying to fix an issue before Lenny is released, I ended up making it even worse. The story goes like this:
There was some problem with the indexing of documents on installation/upgrade (namely, it would take ages for most people upgrading to Lenny, and they would think the upgrade process had hung). So, I go and change the indexing code so it ignores documents on installation/upgrade. Also, as suggested by someone, I created some small example utility to reindex documentation for certain packages. I test installation, upgrades, upgrade of the
dhelppackage itself, the utility, searching for keywords before and after all that… and everything worked.
Only that I made a typo. A typo that would make all indexing to be ignored (except for the example utility, because it was a bit lower level). And I didn’t realise, because it “only” broke some cronjob, a completely different part of the package. And it happens that the cronjob reindexed everything weekly, to make sure that you had reasonably up-to-date search indices. And it also happens that, given that the documentation reindexing was being ignored on package installation/upgrade, the weekly total reindex process was the only thing that could provide the user with indexed documentation. But I screwed up. Oh well.
Someone filed a bug yesterday, and I fixed more or less right away. But this time I spent a couple of hours thinking of test paths and ways to make it fail, and actually doing all that testing. Thanks to that, I found some potential bug in the example utility, that I fixed just in case. So hopefully everything is fine now, if I can convince the Release Masters to allow the new, less broken update to
dhelpto be accepted for Lenny.
I think I need personal QA. Anyone up to the task?
Oct 16, 2008
Maybe that’s something you all already knew, and it’s just me that arrived late to the party, but this is hilarious. I hadn’t used Google Translate myself too much (if ever; can’t remember), but the other day someone mentioned some “funny” translations in some internal mailing list at Opera:
The first translation is… not correct, but somewhat close to the original. The Spanish text is “SOY FELIZ PORQUE CONOCI LA VERDADERA AMISTAD” (“I’m happy because I knew true friendship”) and the translation is “I AM HAPPY KNOW WHY THE TRUE FRIENDSHIP”. As I said, not really correct, but at least it’s somewhat close to the original. Check by yourself:
If you add a couple of exclamation marks at the end, some strange things happen (only half of them are shown in the translation, as if they were escape characters or something). But the really hilarious thing is what happens when you add five of those:
In that case, Google Translate “translates” the same sentence to “KNOW WHY I AM HAPPY THE REAL MURDER !!!!!”. Maybe that means that for Spanish speaking people, friendship plus an adequate amount of enthusiasm means…. murder. Scary.
Sep 22, 2008
Today I was playing with GnuPG, trying to add a couple of public keys to an “external” keyring (some random file, not my own keyring). Why? you ask. Well, I was preparing some Debian package containing GPG keys for APT repository signing (like
The point is, I was really confused for quite a bit because, after reading the
gpgmanpage, I was trying things like:
gpg –no-default-keyring –keyring keys.gpg –import … # Wrong!
But that wouldn’t add anything to the
keys.gpg, which I swear I had in the current directory. After a lot of wondering, I realised that
gpginterprets paths for keyrings as relative to…
~/.gnupg, not the current directory. I guess it’s because of security reasons, but I find it really confusing.
The lesson learned, always use
--keyring ./keys.gpgor, better, never use
keys.gpgas filename for external keyrings, but something more explicit and “non-standard” like
Aug 15, 2008
It’s funny. One month ago, I had never been to Copenhagen. I had two weeks of vacation, so I spent a couple of days there and got to know the city. A couple of weeks later, I’m back in Copenhagen for the YACP::Europe 2008.
In short, the talks were good. Not fantastic on average, but good. In particular, Damian Conway’s Keynote on Thursday morning was really funny, and had food for thought. It was about contexts and the Contextual::Return module (BTW, does anyone know which system he uses for the slides?). Wednesday’s keynote by Larry Wall was about Perl 6, a bit too much into details. It had some interesting ideas about programming language extensibility, but it was a bit too much for a Wednesday morning (without much sleep). Prophet (“a grounded, semirelational, peer to peer replicated, disconnected, versioned, property database with self-healing conflict resolution”) looks really cool, I’ll see if I can have a look soon. Also some ideas about QA and automated testing, to think about, explore, and share with other people.
Many of the lightning talks were very very funny. One of the funniest was the talk about implementing lolcode in Perl6. Really impressive when you think about it, and really funny too. Others, like the Trailer Theory from Adam Kennedy were very funny too.
All in all, we had a really good time, we learned some things, we have some things written down to investigate later, and we met some new people. Yay for the YAPC::Europe!
Jul 22, 2008
Some time ago, Opera announced the Opera Web Standards Curriculum project. It’s a very interesting collection of articles that can be used as “curriculum” to learn about web development. It gets extra geeks points for using a Creative Commons license for the articles themselves. Even the W3C mentioned it
:-)I just found some time to have a look at it, that’s why I’m posting now
The other news is that finally the Opera QA blog is online, and has the first non-hello-world-article (written by yours truly), “Continuous Integration: Team Testing”. I’m very excited about this, because it’s the first time I’ll participate directly in a company blog, and because the IT world needs more (and better) QA, so hopefully we’ll be able to spread the word and make the world a better place
Jun 24, 2008
I don’t really do any Python development myself, but at work I do support some automated testing infrastructure (in this particular case, I’m talking about a CruiseControl.rb installation), and some of the projects that use that infrastructure use Python. The setup is so that the tests are actually executed in the CC.rb server, so I have to have Python installed there, and it has to have some basic dependencies to be able to run the tests.
A couple of times something strange happened: suddenly, those tests would start failing with no apparent reason, and looking at the logs, it looked like some dependencies were not installed (error messages such as
ImportError: No module named sqlalchemy). Of course that didn’t make any sense, because SQLAlchemy is needed for the tests and they were working like a charm for weeks. I was totally and completely confused by the error message, and I tried to install SQLAlchemy again. That solved the problem, luckily, so I decided to forget about it because it wasn’t my thing anyway.
But the problems appeared again. And again. And I got another error message that was really confusing, because it looked like Python was using some old version of some module (a version that wasn’t there anymore, because the code had been updated from SVN). So I just got tired of not knowing what was going on, and decided to investigate enough to find out the root of the problem. And I found something surprising.
What I found is that the famous
python setup.py develop(that everyone told me to use) actually adds the “current directory” to the list of paths where Python searches for modules, so you can develop your module and use it from anywhere. I had heard some comment on that, but I didn’t quite get what it meant, and I don’t think the person that said it realised either.
The fun thing with
setup.py developis that when you have several branches of the same project in the same machine, and you use that to make the modules available… well, I guess that knowing which versions of which modules Python will use becomes an interesting question to say the least. I’m not saying that the way it works is necessarily wrong, but I do think it is dangerous, and people shouldn’t think of it as the “normal” way of developing modules in Python. It should be used with care.
After having realised that and thought about it a bit, I still don’t understand why those modules simply “dissappeared”, but it seems that there was some corruption of
/usr/lib/python2.5/site-packages/easy_install.pthor similar (that file seems to be modified when you install packages with
easy_install, and it had references to the directories I ran
setup.py developfrom, so that’s my main suspect for now). At least I know now that I could backup a working
easy_install.pthfile, and restore when we have problems again, but I’m far from happy with that “solution”
Also, I’m wondering what the hell should I do in the future to prevent more problems, because using
setup.py developsounds like a terrible idea to me. I tried to set
PYTHONPATHinstead, but apparently I failed. Any suggestions?
EDIT: I’m finally using
PYTHONPATH. I have no idea what I tried last time, but using it was easy, quick and clean. I still have no idea why the hell Python sometimes forgets where some modules are, though.
Jun 11, 2008
So, today I was working normally, and suddenly I mispress something… and I can’t switch to other desktops anymore.
First thing I think: maybe some KDE global shortcut manager or whatever went nuts, and redefined my “Switch to Desktop” keys. So I go and check the preferences, and I find that everything is alright.
So I try to redefine the shortcuts again, and I notice that according to KDE, F1 produces
XF86Launch0, and the rest of my F-keys just don’t do anything. I panic, think for a moment about changing the shortcuts to
Ctrl-2, etc., discard the idea because sooner or later I’ll need the F-keys anyway… and decide to reboot. But still I can’t use my F-keys.
Totally desperate, I ask on IRC and someone says “F Lock”. And I go “WTF is that?” but look at my keyboard, and see some key that is indeed labelled “F Lock”. I press it and everything goes back to normal.
Then, the person goes on to explain that Microsoft has very retarded keyboards (in particular, I was using a Microsoft Natural Keyboard) that “feature” a key called “F Lock”, that redefines the “F keys” (F1, F2, …) to be some “useful” idiotic retarded shortcuts for Office applications or who knows what. I was also told that apparently some of those keyboards, when they boot, they are by default in “retarded mode” (mine seemed to somehow remember the setting in my last reboot, because it has never done that).
I just had to blog about this. Amazing.
Feb 25, 2008
As part of my QA work on several projects, months ago I was looking for a continuous integration server. I looked at several, but most of them seemed really scary judging from the documentation. I finally went for CruiseControl.rb, and I have been really happy with it all this time. It’s a really nice, very simple continuous integration server written in Rails. I had it up and running before I even understood how to install the others I looked.
Even though is a really cool piece of software, I was missing some better test result reporting. It was actually there, but only for Rails projects, and unfortunately we don’t have any Rails (or Ruby, for that matter) projects at work. So, I just had a look at the sources to see if I could hook my own reporting there, and the code turned out to be impressively easy to understand (especially taking into account that it’s a rather non-standard Rails application, as it has builders running as daemons, it doesn’t really use a database, etc).
The result is a patch for CC.rb, already submitted to their BTS, that adds a plugin-based result reporting, that can be extended to understand any kind of testsuite. It’s basically a parser that collects all the test passes and test failures from the testsuite output log.
Also, the other day I had another need, which was even easier to make because it could be implemented as a simple CC.rb notification plugin. It depends on the above patch, and it collects all the bugs in the current build, searches in the history of the project, finds out who made the commits that produced the regressions, and bugs all those people by e-mail, pointing out which failures were supposedly made by them, and which build they started failing (so it’s easier to locate the offending code).
It’s not perfect, and it cannot be, but it’s a nice addition to continuous integration. This notification plugin is not public yet, but it might be in the future (especially if they accept my patch as part of upstream), so stay tuned if you’re interested.
Jan 21, 2008
Today I have been one year working in Oslo! Yay! So far the experience has been quite good, so I’m staying here for some more time still.
I’ve also slowly becoming kind of active again in Debian (especially helping
dhelp), although I admit not being very active in any other software project (Haberdasher feels kind of abandoned, because I don’t have any urge for new features). Hopefully that will change…
- Jan 3, 2008 on
Nov 18, 2007
Lately I have been thinking a lot, not to say “obsessed”, with the big picture. I can’t but wonder if that is a general IT industry problem, that big picture. I mean missing it.
My current theory is that computer work is just too hard (or tools not advanced enough?), and there is too much pressure and too hard time constraints to allow people to step back and think about the big picture from time to time, to make sure everything makes sense.
And perhaps that’s why you hire and have QA people, perhaps that is the real purpose of QA. At least I feel that now. I mean, what’s the use of something that has a high “technical quality”, if it just doesn’t make sense? That is actually a big part of the quality, “making sense”. Because of that I’m starting to feel like my job is being a developer that does important things that “nobody has time to do”, because they’re too busy fighting with details. Not in the sense of a “manager”, but in the sense of some “responsible” developer. It’s a really strange job position I think
It’s really hard to measure the impact of good QA in a software project, but I’m sure that is high, probably higher than people use to think. For me, thinking about software projects without QA is a bit like thinking about programming without a Version Control System: I wonder how I had done it in the past, and feel really unconfident without it. How many projects have failed (both from the resources and goals point of view, and from the business point of view) for not having good QA? How many projects have been delayed, or even cancelled, because they lacked someone caring about the Big Picture?
EDIT (2008-5-18): I have disabled comments in this post due to insane amount of spam. If you want to comment, please comment in some other entry