Thursday 10 November 2011

Øredev 2011, Day 2

Day two was very non-techie day for me. I tried to follow the UX track today. And when things get more abstract they are also harder to summarize. But I'll give it a try! :-)

Keynote - Embracing uncertainty - Dan North
The best talk of the day! And what a talk! I think I just fell in love with Dan North... Such a revelation!

For me the presentation was about that we only think that we are agile, but we're really not. Here is my interpretation of what Dan said (most things he actually said :-). He also said a lot more.

The agile manifesto back in 2001 was:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Great!


But now, in 2011, where are we? Well, it's become:
  • Processes and tools over individuals and interactions
    • What? It's true! How many agile tools and processes aren't we using? ...And build tools and deployment tools and processes and...
  • Comprehensive documentation over working software
    • No!? Yes! How many automated tests do you have? Do you use Selenium? Code coverage? Are you doing TDD? It's all documentation, in another form.
  • Contract negotiation over customer collaboration
    • This can't be true!? Sorry, it is! Do you do product backlog planning? Sprint planning? It's all contract negotiations! And often very little customer collaboration.
  • Following a plan over responding to change
    • Just because you have a product backlog and doing things in sprints doesn't mean you're responding to change! What is a backlog? It's just another word for a plan! And face it, how often does the product backlog corrolate at the end of the project? Research of this has been done and 50% of the product backlog isn't correct by the end.
The important thing - the whole thing - about the agile manifesto was to start collaborating! Business people and developers. Have we? No! Why?
Because we are rather wrong than uncertain! We actually crave for certainty. It's built in, we are not born to handle uncertainty. But we need to try to umbrace it.

Then he started talking about what to do about it. Not going in to details about that myself.
You can read more here http://gojko.net/2011/11/10/dan-north-at-oredev-embrace-uncertainty/
And also read Daniel Lee's thoughts on it here: http://danlimerick.wordpress.com/2011/11/10/redev-2011-day-2-rollercoaster-ride/

On little thing he said that got stuck. "What is the sound of one hand clapping?". Stupid question, there is no sound! But think about it... it's a great metaphor for what team work is all about! It's not about doing things three times faster than two persons doing separate things. It's about doing things one person could not have done - at all! Pause a moment and think about the greatness of this metaphor.

Welcome back! :-)

The next of the day was in the UX track :-)

UX: How hard could it be? What it is and isn't - Jeff Patton
I wont summarize, just pick out some goodies.
- Saying that a desing is bad is saying that I think it's bad.
- Developers should be more like doctors than waiters. Not to earn more money :-) But to be more of an investigator of what symptoms someone is suffering of than anything else.
- Our job isn't to build software - we change the world!
- UX has three layers:

Example of just the bottom layer: http://www.craigslist.com/
Example of just the top two layers: Segway! No utility there...
Example of just the top layer: No good example, think "lipstick on a pig"!
UX needs all three!

Programming and minimalism - Jon Dahl
The only non-UX I went to. A lot of music in this talk. From classic music to rock and punk. And I liked that! :-)
The topic was on "what is good programming?". And then he compared music composing to programming.
Bach did a lot of complex music. Then someone thought, well I want something more simplistic. Mozart! After that someone thought, I want to do something more complex. Beethoven! And so this continues. To the days of Beatles (simple) to Led Zeppelin (complex) to punk and so on...
That's how programming works! Sometimes someone comes up with something complex, then someone else seeks simplicity, then... Nothing is better than the other.

Then he stated some good rules:
  1. Simple may be longer!
  2. Clever code is bad code
  3. Any code that isn't doing something is harming your project
  4. Accept constraints
  5. If it isn't business logic, move it to a library
  6. Don't over abstract
  7. Always actively clean up. Constantly
  8. Apply these rules wisely
  9. Simple code is beautiful
  10. Break hard problems down
A greate quote that got stuck: "Sorry for the long mail, I didn't have time to write shorter". Now compare that to programming, it's true isn't it?

Digital typography - Robby Ingebretsen
Meny things I already knew from this talk. But he basically talked about typography as:
Shape, Layout and Technology.
Then he gave a lot of tips for choosing fonts and how to pair them. Think of fonts as a cast for a play. They all may look good for them selves. But it is the total casting that makes it great.
  1. The easy way: one font family - many weights. Never wrong!
  2. Pair a serif with a sans - header in serif, body in sans.
  3. Strong with neutral
And look for contrasts!

Typography is 90% about spacing! On that topic he showed the grid (that he also talked a lot about in his next talk). Draw a grid over a typography layout. If the layout lines up nicely in a grid - you have something beautiful!

Also think about the golden ratio (1:1.618). Size your fonts relative to each other with this ratio. It looks good!

Design composition (part II) - Robby Ingebretsen
When you see something that feels good and looks good and has great user experience. You probably feel  unity! Unity is about: Order, Harmony amd Balance.
When you see something simple it's probably ordered. Design is all about that: Complex feels simple (perception of simplicity). And ordered is the key!
He then showed a lot of examples of great designs that all aligns with a grid, they all fit into a grid!
He also talked about whitespace or maybe empty space or something like that. It's good! Space can be wasted! But empty space is not necessarily wasted space. It's all about creating balance. He then talked about ways to create good balance and showed examples.

Winning the long term users - Donald Farmer
He talked about how to motivate and challange the users that are going to (or you want them to) use your application every day. He talked about always making the application "challange" your users. And preventing boredom.
He stated twitter as an example. He had 6915 followers. That's a challange for him, he wants 7000! Also he mentioned the LinkedIn profile and the challange to get the 100% profile. It keeps the users motivated by challanging them.
You could also create an app which compares your stats with others - like runkeeper.
Visualizing the stats is the key! Of course Donald is some product manager for QlikView, so he showed some examples of how great it is for data (and statistic) visualization.

Your users are like birds on a tree. When the berries are eaten they will fly to the next tree!

Finally he didn't like the word "end users". The end of what!? They are the beginning of something!

But wait! He also showed the hidden notepad feature! Create a txt file and put .LOG at the top. Now everytime you open the file with notepad it will insert a timestamp! Cool!

Cross-plattform UX Design - William Van Hecke
He started talking about his experience from adapting his product for different display sizes: iPhone, iPad and Mac. He stated 12 rules:
  1. New ways of thinking.
    You always have a "core" problem you want to solve. "The soul". And your app is just a window into that "problem". And when you are forced to create new windows you open up new ways of looking at the "problem". And it's good!
  2. Understand guidelines
    But leave them when you wish :-)
    What he means is that Apple has some guidelines on how the apps your'e creating should "look like". Think Microsoft Metro design. But you can also leave them if they don't apply. E.g. Apple says that a certain font should be used. But Apple them selves doesn't use it in the text editor - because it doesn't support italic!
  3. Dead ends (to avoid)
    1. Blow up your app
      I.e. just make your app bigger on a larger display. DON'T!
    2. Squish your app
      Opposite of 1 above - DON'T
    3. Add debris (to the extra space)
      All you will create is a pilot "cockpit", i.e. useless for anyone else than a pilot.
    4. Design is also saying "no!"
  4. Consistency is overrated; start from scratch
    Don't try to adapt your current app to fit into a smaller display. Instead you should start from scratch. See first rule!
  5. The right amount of easy
    Some things are really easy to do on an iPad but a lot harder than on iOS. But other things are impossible to do on iPad, but possible on iOS.
  6. Sharing
    Enable sharing between the different plattforms for the same app.
  7. Information Density
    Give content the space it deserves
  8. Focus
    Minimize distraction
  9. Behaviour
    This means the behaviour your app is encouraging! E.g. avoid the "Manual Autosave" :-)
  10. Consolidate functionality
    Minimize "UI furniture"
  11. Taps are cheap!
    - Super sommon stuff: 1 tap
    - Common stuff: "desktop clicks" x 2 is acceptable. It's actually true!
    - Everything else: go nuts!
  12. Sensible defaults
Point 0: Always serve the soul! (What the app is really for).

He also talked about the great 5 "Why?". Ask someone "Why?" questions to a response five times. It will get you the answer to the real problem.


That's it. Have to close! Must drink some pale ale now ;-) Once again I favor ale over typos.

Finally, I'm sorry for the long blog post, I didn't have time to make it shorter...

2 comments:

  1. thanks for letting those of us not lucky enough to attend Oredev learn some new things via your blog post! You did a great job of capturing the essence of what sound like great presos. Thanks!

    ReplyDelete
  2. Read my own post now. Man, what a bad writing! And all typos! It's hard to get it right when you dump your brain in a blog post... :-)

    ReplyDelete