A tablet is a big phone, not a small laptop

...and that's why I believe Windows 8 fails

Someone (probably at Apple, at least they where first) must have thought "Why can't I make this iPhone bigger but not use it as a phone?" And voila, the iPad was born. Story probably not true, but the basic idea turned out to be a huge success.
Google and Microsoft panicked. Google made the right decision and thougth "Well, we can also make our phone OS on a bigger display..." and very soon they had a competitive solution (tablet) on the market. Today Android tablets and iPad are almost equal players.
But Microsoft made a different, strange, decision: "Why can't we take a laptop/PC and make it smaller?" "Yeah! That's great let's do it!". But, I don't think it was such a great idea - it is not what you want from a tablet.

A tablet is the be thought of as a large smart phone - not a small PC.

What Microsoft should have done

Microsoft now started working on modifying Windows so it would be suitable on a tablet. But. This took time. And with time the market for another tablet player got smaller. And at the time of release for a new Windows I believe the market is gone for a third player.

Microsoft should instead have thought: "We can also make or phone OS (Windows Phone 7) on a bigger device". And they would have had a product on the market quickly. And also, maybe, they wouldn't have had to "kill" Silverlight (maybe it was inevetable anyway? Unimportant here) and "kill" all the existing developers for Windows Phone 7 out there. Instead they made them unsure of what was happening and made most of us annoyed by all this uncertainty. And now all developers have to relearn (Windows RT).

Apple made the right choice of separating their laptop/PC (MacBook/iMac) and iPhone/iPad OS. And all developers had the same old "iPhone" platform (almost at least) to work with.

Windows Phone 7 should have been renamed to Windows RT (good name huh? :-)) and being a phone/tablet OS. Windows 8 should have been an updated Windows 7 - and they should have made it the most brilliant PC OS out there, it had the potential!

What is left?

Probably Microsoft thought that tablets would kill the PC market. And maybe they are ahead of time - that might be the future. But not now (if ever)! The PC is usable, and we need it!

Windows 8 became, primarily, a tablet OS. With a minor updated Windows 7 behind the new start screen.

But since the tablet market for Windows now is basically gone, the market that is left is the PC market. And most Windows 8 installations will probably be on PC. The market for PC is still here. But what do we have? A tablet OS!

Come on. You just have to relearn!

Windows 8 on PC feels awkward. I know, I'm using it. And I'm not alone of feeling this. I have talked to colleagues, family members and friends. Most feel the same. The start menu is in the way for my every day work (I just want to start apps - not watch the weather and top news). The charms feels unintuitive (on PC) and finding stuff is harder since I have to relearn.

And, believe me, I'm fine with relearning. When Office 2007 came I thought "Damn, now I have to relearn. But this is really to the better! I want to relearn, because this feels right! This will make me more productive in Office".

With Windows 8 I don't feel that. I don't feel that is so much better. I don't even really get the point of the charms and start menu. I don't feel I'm more productive. But that's my opinion.

And the biggest fail and confusing thing is the switching between Metro mode and classic mode. What is what? And why do I get tossed around? (That's mostly my wifes opinions :-) And the Windows RT apps on a PC monitor? Please, no. On a PC I want to resize windows, I want multiple windows, I want more details, and so on. And what is really the difference between RT and 8? I know. But do customers know? Do they even care? 

Fail? Really?

Well, probably not a complete fail. Customers are curious and they want the latest. And the new Windows really looks nice, and it works great. So Windows 8 will be sold. On PC. But how will it be received? Only future will tell. But my opinion? The new Vista, but another kind of fail - the "wrong idea fail". And that's even worse.

Why are you so upset about this, why do you care?

Because I'm a Microsoft fan. I love Microsoft technologies, tools and frameworks. And I'm a .NET developer too - and I love that!

So I'm upset because I'm disappointed. They could have made the right decisions but made the wrong ones.

I might be wrong about all this. And in fact, maybe, I hope I am. But unfortunately I don't think I am...

Customers are carpenters

This is a follow-up on my previous post Developers are not carpenters. Where I wrote about that building a house is not the same as creating (or building) software.

But if I where to build a house, and hired a carpenter (among many other craftsmen) I would know approximately how long it would take and how much it would cost me. And even though I hired someone to build me the house I would be very interested in the progress and what’s going on and problems etc.

Even if I was to buy a pet (my alternative metaphor) I know how much different pets costs and what they require.

But, most customers don’t really know how much software costs and how long it takes to build it. And, in particular, they are not really interested in the progress when building it.

Why is that? After reading a post by Scott Hanselman, Please Learn to Think about Abstractions, it got me thinking…

The reason I would be so interested in the process of building my house (and I approximately know how much it costs and how long it takes) is because I know quite a bit about building houses! I also know some about pets. But most customers know nothing about building software. The same would probably be true for me if I knew nothing at all about building a house. I would probably accept any price the builder said and probably accept anything he/she says about the time it would take.

I think all customers (that are responsible for the applications in the company) should take a beginners course in software development. If they knew more about programming I believe that better software will be built for them. Just as I will get a more suitable, better, house built for me because I know some about building houses.

And I think most customers is like me – they know how to build a house. But they don’t know how to build software. And that’s why they are sometimes frustrated at us when we ask them a lot of “stupid” questions about building their software.

But do we developers want our customers to know about programming? I hope we do. A couple a months ago we rebuilt our bathroom. We hired some craftsmen to do the job. I was very interested in the progress and followed it in detail and almost every day gave my input and had a discussion with the craftsmen. And when it was finished they talked to me and really emphasized how much they appreciated my participation. They thought everything went very smoothly and was to the better. Both for them and for me.

Developers are not carpenters

At least not figurally speaking :-)

I spoke to a colleague the other day. He had just had a meeting with a (potentially new) customer. This customer had had some bad experiences from previous suppliers. The customer then said: “If I want to build a house. Don’t you know how much it will cost me and how long it will take to build it?” And my colleague tried to answer: “But what kind of house?” “You know, a standard house”. My colleague tried his best “But that still depends, where do you want to place e.g. the kitchen and how do you want it to look like and design it etc. etc.” But the reply still was kind of “As a carpenter, you should know”.

But the metaphor is far from complete. Creating software is not building a house! Software has a soul, a heart, a life. It needs to live, grow up, mature, be fed, be nursed. And who will do that? Both the customer and the developers! And I think that it has been their main problem all the time; as a customer, the more involved in the development you are the better development it will be.

So next time. Reply with “How much is a pet? And how long will it take to breed it?” And also, you just don’t buy a pet and think it will take care of it self and don’t need any attention (the whole point of having a pet at all). The metaphor is just as good (or bad).

 

…”What kind of pet?” “A standard pet?”

My estimates are too optimistic

First of all, I’m not talking about story points here. As a consultant, as I am, most customers don’t care about story points. They care about –What will it cost? and the answer depends on how many hours I, or my team, will spend (don’t tell me about fixed price! I don’t want to here about it!). Story points may solve a lot of problems, but it requires the customer to be accustomed with it (and perhaps use agile methods already). So, still, very often I estimate in hours. Usually for rather “small” improvements/features/changes.

But almost all the time my estimates are too optimistic. And it doesn’t help anyone. Especially not me! So, why? I think it’s because I want to give the impression that it isn’t such a big effort so they will make an order. Or I want to give them the most optimistic estimate for being… optimistic! Or perhaps they think I’m a crappy developer who requires all that time for such a “simple” change/feature. Honestly, I don’t really know…

But, I’ve started to use a simple test to see if my estimates are too optimistic. Very unscientific, but it has never stopped me before, so why should it now :-)? Something like this:

If I estimate a new feature - or anything - to, let’s say, 20 hours. Then I question myself (in front of the customer or not, doesn’t matter): is it just as likely to take 10 hours as 30 hours (±10 hours from my estimate)? -No! 10 hours is not likely at all, even if things runs as smoothly as it could never go (has never happened yet, but I never loose hope…)! But 30 hours is not unlikely at all (if something unexpected happens, and it usually does). Not to mention 5 hours compared to 35 hours (±15); 5 hours is ridiculous, 35 is not likely – but not ridiculous! 0 hours is impossible, but 40 is not (okay, this has to be reasonable; 0 hours is always impossible and 100 hours probably not, but all estimates should therefor not be 50 hours). And all of this is my signal that my estimate is too optimistic.
Then I have to adjust my estimate until the min value is just as likely (or ridiculous) as the max value. Is 15 hours as likely as 35? Yes. Is 10 hours as likely as 40? No. Okay, so maybe I will settle at 30 hours (or something in between, like 28, but I keep things simple here)? 10 hours is as likely as 50 hours (50 hours should not happen). And 20 hours as likely as 40. But wait! 20 hours was my initial feeling! Is that as likely as 40 all of a sudden? Yes, I would say it probably is. In the end, it may take 20 hours after all (my initial feeling was correct) and then I think all I have is a happy customer (because I said 30)! I would definitely have an unhappy customer if I say 20 and it takes 40, compared to that it takes 40 and I said 30 and so on... And to be honest, if you have ever made an estimate that ended up being correct (or very close, yes it has happened) it was an estimate that had some “air” in it – right?

Of course, I could give the customer a min value and a max value. But most customers don’t want it or don’t like it.

Rules are made to be broken

Through my years as a software developer I have built (or seen other developers built) systems that are very tightly coupled around rules. Very often the rules are explicit and are not my own, but from the business aka “business rules”.

Since it is a rule I start to design the system around the fact that the rule is always 100% true.

But what I do is locking my self in. Why?

Because. A couple of years (or months or weeks) later the rule is no longer 100% true. Very often the same person who told me this rule could never ever be broken is the one telling me to brake it. Since the system is designed around the fact that it can’t be broken, it’s usually pretty (or very) cumbersome to change it.

It can sound something like this.

– Why can’t I do “that” on “this page”?
- Well, because it’s built that way. It is not permitted to do that.
- But I must be able to do that!
- But, you told me at (some date) that it was a rule?
- Yes! But not when I want to do “that”!
- . . .

But it is understandable. We want to be certain about some things when we initially work out the demands for the system. But the users every-day work life is all made up by exceptions! It’s all made up by ways to brake the rules. And if you think of it, it would be a pretty boring job if it wasn’t so. You could easily be replaced by a machine.

And when you think about the rules (laws, morals and ethics etc.) that our society is made up out of. There is always an exception for them. If I where to build a system around some society I would definitely build a strong rule around not allowing anybody to kill anyone else. Most countries have a law for that! But. Depending on which country you live in, it is – sometimes – ok to kill someone. If you find an intruder with a knife in his hand when you come home and he attacks you with the knife, you are (by Swedish laws at least) allowed to kill the bastard (to defend you own life). In some countries *cough* or *cough* states *cough* (not mentioning any) the government holds the right to execute civilians. My system wouldn’t be built around that exception.

What am I trying to say?

Something like; always prepare your system to be able to brake rules. It will happen eventually. It’s hard. I know. It’s much easier to write “if (true)” than “if (true well… but…)”.

Or at least always prepare yourself for it, if you don’t want to prepare the code. And allow it to happen. It’s called being agile :-)

Øredev 2011, Day 3 - it's all over, but something new begins...

I'm so happy I got the opportunity to go to Øredev. It's such a huge inspiration and gives a lot of new ideas and new ways of thinking and coding.
It's been three wonderful days. Great speakers, great subjects, great ideas, great people, great food and great organisation from the Øredev crew! Perhaps to many geeks in one place though (and to few women)..? :-)

If you just gonna read one thing of all the session reviews below, skip to the Dan North review.
Otherwise, keep reading :-)

Keynote - Stack Overflow: Social Software for the Anti-Social Part II: Electric Boogaloo - Jeff Atwood
Pretty good speak. Nothing new. He gave his thoughts on how Stackoverflow works and how it became popular. End of story.

Building HTML5 Applications with Visual Studio 11 for Windows 8 - Tim Huckaby
The title doesn't corrolate to what he actually talked about. He actually didn't have time to show any building of any application at all. He didn't even show Visual Studio 11(!) Tim is a really good speaker though, so it was a very giving talk anyway.

He talked about HTML5 and that it's more of a "concept" than a standard. As we already knew.
Then he started to talk about what Steve Jobs did when he introduced the iPad. He actually helped Microsoft! Instantly, Steve "killed" flash instantly. And if Flash is dying, so will Silverlight. In the end. Tim didn't really say that, because he was recorded. But he someway did. And he felt sorry, because he had been a devoted WPF/Silverlight developer for many years.

Steve wrote this (saying that Flash will never be an option on iPhone or iPad), and apple responds with this:

Then Apple responds with this:

They actually didn't. But it's kind of what they did by not supporting it (if you don't have an iPad; the "Lego" brick is what is shown instead of the flash plugin when you browse a site with flash on it). Really funny!

Anyway. Apple loves HTML5! Google loves HTML5 (and is the most driving force in the HTML5 area)! And, Microsoft loves HTML5!

But. There's always a but. We, developers, are not representative for the vast majority of users out there in the world. There are very few browsers out there with HTML5 support. Because there are a lot of old browsers (and computers) out there. And, on the other hand, Silverlight is installed on more than 70% of all computers ou there. It's a bit of a dilemma! So, probably, we wont be doing full-scale HTML5 applications in the near future. And Silverlight will be a tempting option for a few years to come. But we eventually will be doing HTML5! Either we want it or not. Steve actually never wanted a specific language for the iPhone, he wanted all apps to be HTML5. But he also realized that it wasn't an option, the market wasn't ready for it.

So. Is it a step back to the old browser-support hell we had back in the late 90's? Yes! Does Flash and Silverlight offer better graphics, interaction and effects? Yes! But! HTML5 is a standard! And it will be available everywhere! The browser will no longer be filled with plugins, it will be the plugin. And don't worry about the other things. HTML6 is already on the drawing board. And this time it wont take 10 years to finish it!

Delivering Improved User Experience with Metro Style Win 8 Applications - Tim Huckaby
Part II by Tim. He didn't have many slides in this presentation. Well, he did. But he was mostly showing a lot of cool examples and demonstrations of Windows 8 (he hade a to- notch developer tablet with the latest build of Windows 8 on it - it was shaky :-). He also talked, and showed, a lot about NUI (Natural User Interface), YES! So it was kind of more a demo of Windows 8 and it's capabilities than anything else. So it's hard to summarize the talk.

But the coolest thing! He had a touch screen from a swedish company (from Lund) http://www.flatfrog.com/products running Windows 8! He said it was the best touch screen he had ever seen or used! Nice! He also demonstrated the Kinect API for Windows (on Windows 8). He also braught up another guy to the stage (whom he had met in the bar the night before) that had created an eye recognition app. All with .NET and two simple web cameras! Impressive!

One thing that caught my mind was this slide:

• NUI is mostly for consuming content, not creating.
• Meaning, not for CRUD-apps, which I mostly create :-( He's right too.
• Do not conform to the Windows GUI Spec! Yay!

Functional Javascript - Anders Janmyr
He started the presentation by mentioning Dan North talk by saying that Javascript is an uncertain langauge :-)
Otherwise this talk was not what I thought it would be. I thought I was going to learn some cool javascript stuff or architecture or something. But I learned nothing. He just burped up a lot of javascript functions. A lot! And that's it! What functions do you ask? Well: mixin, map, curry, fibonacci (of course) etc etc and finally the famous Y combinator. Totally waste of time! I could as well have read this by my self - if I had wanted to.
Do I have to say I left a red vote in the basket for this presentation?


Data Visualization with Canvas and CoffeeScript - Trevor Burnham
Another red vote in the basket :-( This was mainly a live coding session.
One great thing I learned though! Never use CoffeScript! For the second time in a row I see a CoffeScript presentation and the presenter gets lost. He had to give up! He sat a long time trying to figure stuff out but after a, way to long, time he went back to copying a prepared code. And this guy is an expert! It felt that he didn't have any tools to help him find the problem. Here is why I think CoffeScript is not something for my company (Active Solution):

1. Adds unnecessary extra skill requirements.
1. You have to find people (competence) that know CoffeScript. It's not something you learn in 15 minutes.
2. You lose your Javascript skill. Because you learn CoffeScript instead.
3. Adds another layer of abstraction that's not needed. And when something fails..? I don't want to think about it.

What about the Data Visualization part? He didn't really got there... He showed some bubbles that floated around on a HTML5 canvas.
He also had a slide that was a bit depressive.

• The canvas in HTML5 has quite bad performance if you want to do more advanced stuff. But it gets better all the time when browsers starts using the GPU more and more.
• Handling mouse/touch events on a canvas is hard. If you want user interaction, your'e on your own...
• No "jQuery of Canvas" exists. But it probably is coming soon.

Patterns of Effective Delivery - Dan North
Dan North had some expecations to live up to from yesterdays talk. And he delivered. You like this guy so much that you get blind for what he says. You accept it all. But he actually has some really mind blowing thoughts.

First of all he was trying to encourage us. His experience as an agile mentor was that he was trying to get developers from stuck to anything. From zero to anything. Because that's an infinite improvement! :-)

Then he talked about optimisation. You need to optimise for something, and you always are.
Agile, as we know it and practice it, was optimised to be easy to learn. Optimised to be teached! Not optimised for effective delivery! It's true. Poker planning, backlogs, sprints, daily meetings etc. It's all about giving certainty - and we want to embrace uncertainty (if you remember my review on yesterdays keynote).
Then he started to talk about some patterns he thought could help to start thinking in new ways.

I'm not going in to details of those patterns because I'd be up all night. But basically:

• Don't be afraid to not do TDD when you are really good at TDD. Because you know what TDD code looks like. This was on the pattern of "spike and stabilise".
• A pattern he called "ginger cake": Don't be afraid to copy and paste code (!!!) Because you will eventually clean and adjust that code anyway. And sure, you may copy a bug, but more important - you copy a lot of good code! He compared it with a recipe he had for chocolate cake. On another recipe it said "Like chocolate cake but with ginger" :-) As an expert (or baker) you know when to break rules (or adjust a recipe to produce ginger cake instead of chocolate cake).
• Be prepared to delete/remove your own code. Don't be emotionally attached to it. Instead, prepare to throw things away. Embrace uncertainty! How? Make small pieces of code that are specialized at one thing. Then thay are easy to throw away and replace. When you create a dragon of code, things get scary. Things that can be done better or adjusted for outer changes must be thrown away and replaced. Make it easy to do it. A pattern he called "short software half-life".
• "Create urgency". You will never learn how to swim if you never remove your armbands. You will never learn how to ride a bicycle if you don't remove the support wheels!
• A lot of other patterns he just briefly mentioned. 

He emphasized that you don't have to agree with any of these patterns (it's his). And, they are very contextual. In one context they suite very well, in another they may not.

But! The most important thing of all: what are you optimising for?

See this talk when it comes out! Well worth it!

From Solid to Liquid to Air, Cyborg Anthropology and the Future of the Interface - Amber Case
This talk really felt like you were listening to a TED talk. And she actually had talked at TED. She was very good! She talked about how we really already are cyborgs and how we have changed our tools from being an extension of physical selves (like a hammer) to extend our minds instead. She also hoped that mobile usage will stop drawing attention from other things to just being an extension of our selves. In some way...


Thank you for three wonderful days at Øredev! Hopefully I will have the opportunity to come back (maybe next year?)

This time I actually reviewed (briefly!) my post before publishing it. As Dan North said: from zero to anything is an infinite improvement :-)

Ø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...