I’ve just come back from SparkUp Conference which is probably the first conference focusing on web development, web design and user experience in Poland. You can find a few words about the conference itself at the end of this post, but my reason for attending the event wasn’t to judge hosts but to catch on with new trends in web design.

I don’t feel like an expert in the area so I expected to hear pretty much new information and learn what we’re doing wrong.

Make it simple

If I wanted to point the only, most important message repeated over and over again at SparkUp it would be: make your design less cluttered. The more things you’re trying to pack into a website the harder it is for user to find what they’re looking for. The more elements you try to stress using visual tricks the harder it is for user to focus on the real goal of the site.

It is the old lesson you can say and you’ll be right. If the world has learned one thing about web design from Google this was the thing. The change we made in just a few years from packed sites competing for our attention to single-purpose sites with clean and simple design is impressive. Yet it appears we need to be told that still after all these years.

Learn how to keep user on site for more than 30 seconds

This is another pretty obvious message, but I’m not surprised at all we heard that. Most sites suck at keeping user’s attention for a minute or so. What more, if I wanted to point the biggest failure of design of this blog it would be exactly this – keeping you, dear readers, on the site for a longer time and making you click something than close tab button. Bounce rate close to 80% is nothing to be proud about.

Anyway it looks like new visitors don’t find here what they’re looking for because it can’t be found easily enough or just named wrongly. For this discussion I just won’t consider my writings can be boring or stupid. But coming back to the point, if we aren’t able to draw attention of visitors during first half of a minute they’re gone and they’re not coming back.

Interesting thing is it works the very same way with mobile applications downloaded to our smartphones. Even though it isn’t a website and the app sits on our device we won’t invest much more of our time.

It’s not always the user who is the king

This one was a bit of surprise for me, but it appears you may want to build a site which is sub-optimal for users but maximizes your other goal, namely advertisement exposure. I never looked at that this way, but to some point this does make sense. This also explains why typical news sites suck so much.

Not everything has to be perfect

We have a number of different browsers. Some of them infamous for their bugs or non-standard behaviors, IE6 being the most notable one. When designing a site we often try to polish every detail. But it appears that the good enough principle works here as well. Users won’t notice that corners aren’t rounded in Internet Explorer or there’s no shadow in Chrome or some graphics aren’t perfectly aligned in Firefox. After all they don’t switch like crazy between different browsers. And they don’t come to your site to judge design but to achieve some goal: find information, buy etc.

Web 2.0 with human face

I pretty much expected to hear a lot of web 2.0 and social media crap thrown at every presentation during the event. And I was positively surprised. Of course there were a lot of social media apps used as examples but it wasn’t pushy at all. That’s natural some of strategies used by social media sites can be used more universally and that’s basically how this content was sold on the conference.

Summary

I’d say I expected to hear more novelties and it appeared people keep saying pretty much the same things you already know, if you use some common sense at least. This isn’t a bad news however. You just don’t need to use all new stuff to build a great site.

What more, being a few steps behind may even help you, as not every idea adopted by the industry appears to be great. A good example is using a lot of Flash, which is sometimes credited as overused technology.

About SparkUp Conference

This was the first edition of the event and hosts need to improve a lot. A list of glitches is pretty long: slides were hardly seen (very dark and blurred) despite three projectors in each room, some problems with audio, coughing wifi, not enough snacks during breaks, a very long line for lunch and light on the stage virtually blinding presenters. Even Twitter coverage was poor. But the worst organizational glitch was a lack of host.

There was no one trying to keep the schedule, shouting at people staying too long at breaks, introducing presenters, running with a microphone during Q&A sessions etc. One person for each room would be enough. All these issues can be ascribed as problems of a first version, but AgileCE this year was also version 1.0 and it was organized way better than SparkUp.

Another thing is presentations quality. To be honest I expected more. Not that I complain about caliber of speakers. Actually I’m neither web designer nor web developer so celebrities from that niche are anonymous for me anyway. But I expect people would be prepared to deliver their presentations, and their speech would go rather smoothly. Not that all presentations were mediocre, but a couple of them were definitely below-average.

When I was considering attending AgileCE I had doubts how it would eventually go, but after the conference I’m sure I’ll be there next year. With SparkUp it is the other way around: I thought it was a great idea for an event, but I’m not so sure if I’m going to be there next year.

English version of Wikipedia has recently gone through face-lifting. Now GUI is a bit smoother, a bit nicer. A thing I don’t really care about, but fine, people would like it.

At the same time they moved search box from the left sidebar to top right corner. What can I say, the new place is used on different sites to locate search box. On different sites, yes, but not on a freaking Wikipedia. On Wikipedia it is always on the left sidebar. Always. I mean it was until someone decided it to hide somewhere else.

As a comparison you can see Polish version of the site with the old design.

You may laugh at me but I spent like 20 seconds looking for search box. Why? Because I got used to the place where the control was and I expected it there. I would be as much confused if Google suddenly moved search box somewhere else.

I bet that if Wikipedia had left search boxes in the old place and in the new one vast majority of people, like 99%, would have used the old one.

Pretty much the same happened with Microsoft Office 2007 with redesigned menus. I use it for about 3 years already and it still happens I get frustrated trying to find one of these options you use once a couple of years. With the old Office it could be found in Options or other Settings. And now it is um… somewhere.

The problem is users get used to your design. And then, they expect there won’t be significant changes. And if there have to be a change people expect it will be done the way Google chose when face-lifting search. They polished graphic too, but the search box is exactly where it used to be for centuries.

If you decide to move important piece of your GUI somewhere else or, worse, redo the whole GUI just think about it once more. You will likely confuse your users.

I don’t say it has to be wrong automatically. Sometimes you just have to invite new design; otherwise we would still use command line interfaces. But if you took Windows 95 user sat him in front of Windows 7 he would feel familiar. Start menu, task bar and windows with the same elements: menus, status bars, title bars etc. And that’s not without a reason. It easier to switch people from one application to another when they know which function is where and they aren’t surprised with the way things work.

Personally I don’t really get the Wikipedia move. If I really wanted to move search box I would rather put it in the middle, Google-way, but most likely I would just leave it where it was. I don’t see how this change was needed but I do see how it confuses users. And that’s exactly the GUI redesign trap.

I recently registered to last Krakow .Net Developer’s Group meeting. Group’s site is run on SharePoint Server. What does it mean? Well, probably administrators can use vast choice of different web parts available for share point and can configure security in details.

But what’s in it for me as a user? Let’s talk about simple event registration process. What you need to do to register for the event is:

1. Find a list of attendees just to learn there’s no ‘register’ button.
2. Learn you need to sign in to the site (SharePoint server in this case).
3. Register on the server.
4. Find confirmation email and confirm your registration.
5. Go back to the event site to learn you have to need to fill your profile.
6. Fill your profile and learn it works pretty inconsistently.
7. Go back to the event site to find (surprise, surprise) you still can’t register to the event.
8. Check your email client to read useless information that you filled your profile. As if you didn’t do it seconds ago.
9. Learn you need to apply for the group which organizes event before you can register.
10. Apply for the group. You need to fill 3 required fields instead of checking the ‘I want to go to the goddamn event’ flag.
11. Read an email telling you that you’ve just applied for the group and need to wait for acceptance. The email does it in completely cryptic way.
12. Wait patiently.
13. Get an email with cryptic information about you being accepted to the group. Woo-hoo!
14. Go back to the event site to find out there is no damn ‘register’ button whatsoever.
15. After few random tests use ‘new’ and ‘add new record’ options respectively to finally register to the event.
16. Read an email telling you how “adding registered user in localization workflow has been completed.” What the hell?

I was determined so I made it to the last point. In any other case I’d leave somewhere between point 5 and 8. Is this the goal of hosts? I didn’t think so.

Actually at least half of this rant should be addressed to SharePoint team but if administrators took a while to think what a pain in the neck it is to register to their event they might reconsider the process. They should unless they want to keep it elite and drive potential attendees away. “You’ve passed 16-point registration process; you’re worthy; you are allowed to join.”

A nice story, but what is it really about?

If you run or build a site with some kind of registration make it damn easy. Think about the easiest possible way of registration and then rule out at least one step. Do it or potential users will remain potential forever. They will walk away faster than you think.

• If you can live with anonymous users don’t force them to register (but create an incentive for them to do so).

• If you don’t need to get confirmation of an email address don’t ask for it.

• If you don’t need to get full profile of users just leave it as an option, don’t push it to the front page after first login.

• Don’t create few-step registration process. Just don’t, OK?

• Use OpenID mechanism as an option which would make registration much easier and much safer for users.

The other story is SharePoint which does really crappy job as CMS standing behind internet sites. There are loads of better options. SharePoint was aimed at intranet sites and even there it doesn’t do a good job. Moving it to the internet is just wrong.

A couple of days ago GMail greeted me differently. Instead of good old inbox I saw big shiny add prompting me to try out Google Buzz. Add I instantly hated. I was all: “Give me my damn inbox back. I don’t even want to seek damn ‘skip this’ link. I hate you Google!”

Wasn’t I supposed to write why I think Google Buzz is good? Well, thanks for reminding me.

Anyway, I finally checked Buzz and while I can’t say at the moment whether it is good product I can already say it is significantly better than recently released Google Wave when it comes to product management.

Product Communication

I learned there is something like Google Buzz because of this annoying advert I mentioned above but the only thing I was looking for then was ‘go to my inbox’ link. I didn’t even read what the heck the thing is all about. But the next thing I noticed was another link in my GMail navigation panel waiting patiently to be clicked. A kind of passive invitation – click me if you’re curious, click me when you’re ready.

With Wave it was a different story. People started writing how cool or how crappy Wave was. I checked it to avoid being out-of-date. If I wasn’t reading what Google is going to bring up next, and face it: most people don’t, I wouldn’t even know there is such thing as Wave.

What does it teaches us when it comes to product management? Make it easy to learn about your new product. Buzz is there, waiting for you to take a look whenever you feel like it. You see it every time you click on your GMail inbox, which many people do very often. Sooner or later you will check what the new product is. If you’re one of these huge corporations which gets a lot of PR you can also base on your fame and let people talk about your product, but it won’t be anywhere as successful as integration with one of your current applications.

First product is just one click away from you all the time. Another requires much reading, finding out what it is and getting an invitation. The latter is hell lot of work for average user.

Leverage Existing Products

Google has Blogger, Google Talk and Picasa, all producing some kind of feeds: posts, status messages and information about new pictures respectively. This may be automatically pushed to Buzz and magically people use the new app seamlessly. My first thought was: Twitter and Facebook statuses should be next. Well, actually Twitter is already integrated (one-way, but still). It just isn’t enabled by design since you have to point Twitter profile to finish integration.

Wave doesn’t integrate with anything. This is yet another stand-alone application. The only thing you can get is email notifications, but that doesn’t help with feeding Wave with any content.

If you launch new product addressed to mass market make people use it without even being aware of the fact. Sure, there aren’t many companies which can pre-configure everything like Google. Apple, Microsoft, maybe a few others. But even then let people do the configuration part only once and make the rest happen automatically. Even when someone isn’t coming back to the app as far as it goes on auto-pilot you build your user base up.

Make It Simple

Buzz copied Facebook and Twitter GUI, which already works great. One textbox where you write something and post/publish/submit button. OK, there’s configuration too which I don’t even try to learn at the moment. Somehow people I know just pop up and I start following them. When I wear my user hat I don’t even care how it happens. What I care is I can follow plenty of my friends and do it easily.

Wave tried to do too many things. Collaboration, conversations, pictures, videos, documents and all the stuff. Wave does many things but neither of them is done well. And worst of all it doesn’t help to link with your friends which, for social media app, should be the single most important goal.

Trying to get the product right at the first time is doomed. Trying to get every possible feature great with first approach is impossible. It’s much better to choose one or two features, do them good enough and then fix them until they’re great. Until then don’t push more half-assed features than you have to. If you do few key things right you don’t need to have everything on board at the day 1.

Summary

I don’t say Buzz is a good product. I don’t know yet. The thing I know is I will use Buzz because I already set custom status messages at Google Talk which should automatically make their way to Buzz. The same way a bunch of my friends will use it. Plenty of them don’t use Twitter or Facebook so this will be the first virtual place where we meet and that’s where Buzz kicks ass from the day 1.

That’s all thanks to very good product management strategy. Much, much better than it was with Google Wave.

Just a couple of days after launch more of my friends use Buzz than Wave. That was left-handed anyway, since it’s pretty easy to have at least 1 user.

It is possible Wave today is better product than Buzz. I’m almost sure it took way more work to bring Wave where it is today than to launch Buzz. And yet, just because of very wise product management, Wave folks should go ask Buzz team for training.

Even if tomorrow I’m going to learn Buzz sucks, I’ll keep coming back because:

• I use it anyway (seamlessly)
• It is at hand all the time
• It is used (seamlessly) by more and more people I care about

None of these things can be told about Wave.

It appears not only the product itself matters but also how you drive it.

You can approach this post in at least four different ways. Your attention can be drawn by Google Wave part, namely my rant on the subject, or by a list of thing which you should avoid while shipping your application, which is a kind of lesson learned from the part one. You may also come here for both or neither of them. In the latter case I guess that’s quite a success I kept you here up to this point.

Anyway the whole thing starts with the story about Google Wave. Feel free to skip to the second part if you don’t feel like reading yet another rant about yet another Google application.

Google Wave

Lech invited me to try out Google Wave the other day. There was pretty much buzz on Wave recently so it’s a chance to set my own opinion.

I took my tiny netbook and logged in to Google Wave. The first thing is, what a surprise, an introductory video. A cool one. I could see top left corner of it. Oh I soon noticed “full screen” button on the frame so I could see whole video, which at the same time became completely irrelevant since the guy was showing other frames which I could no longer see since I full-screened frame with the video. Well, you don’t have another chance to make first impression they say.

Hey Google, have you ever heard about this little thingies called netbooks which are so damn popular these times? Yes, the ones with 1024×600 or similar screens. I must tell you Google Wave sucks when you use one of these.

I tried to play with Wave for a while trying to find the way of use just for myself. Nah, too slow, too feature-poor and too buggy. I thought it might be a replacement for good old Google Notebook but I couldn’t even paste a picture there, easy way.

But that’s all fine since they told us it’s the collaboration tool, didn’t they? And as far as remember there isn’t much collaboration happening between me and… um… me.

An occasion to test collaboration features of Wave appeared soon after. Along with Lech, Peter, Martin and a couple of others we shared two waves trying to run a discussion and collaborate online.

What can I say? First thing Google Wave is buggy. We found long list of issues which annoys us, huge lag on slower machines being probably the worst one. If the application you use cannot display characters as you write them something is fucked up big time. Hey Google, have you heard that these neat netbooks everyone uses aren’t very fast machines? Well, I tell you, not even close these fancy powerful machines you develop your code on.

Let aside quality. “Ship early” they said. What about functionality? A tough question. I thought about the most obvious scenarios like editing a document by a couple of people at the same time or a discussion on some subject or a hard-copy for intensive brainstorming… Actually none of these.

Co-editing a document is a flawed concept as a whole. If you try to write something and your cursor is jumping all over the screen because someone else tries to write his part just above you’re all “WTF?? What the hell is happening with this darn application?” I don’t know how the problem will be dealt with but definitely some other way than broadcasting each keystroke among all collaborators.

Over to discussion part. I must say threaded conversation in Google Wave looks neat. Nothing like phpbb forum. It’s really nice. You even get use to vague way of editing the conversation pretty fast. The problem is it becomes cluttered virtually in minutes. If you’ve seen some multi-threaded flame wars on popular portals you get what I’m talking about. It takes just a dozen of posts and you start losing your focus. After few dozen you no longer know which subject was discussed in which part of the thread, multiple sub-thread are forked by people utterly disagreeing with one little sentence thrown between the lines as a joke and people start wandering in different directions which happens during every uncontrolled discussion. If you happen to be offline for a couple of days finding any reasonable order in the thread becomes a great story for the next Mission Impossible movie.

Maybe brainstorming then? Maybe, if you try hard enough. This scenario is basically the mix of two above and you feel exactly the same pains. The main product of brainstorming ends up somewhere in the middle of conversation between “be right back” and “this feature sucks” messages. And no, co-editing the post doesn’t become easier just because it’s record of brainstorming.

And one more thing – every of these things you could do with other tools, namely Google Docs, any IM chat (Skype is fine) and shared mindmap (MindMeister anyone?).

This brings me to sad conclusion: Google Wave is released too early (e.g. is too buggy) and solves no real problem. What can we learn from this example?

What You Should Avoid When Releasing Your App

• Don’t release too early
If your software wouldn’t pass 15-minute acceptance tests of a person who just skim through the app it isn’t ready yet. Release early doesn’t mean you can release complete shit as long as it’s early. If the app is too crappy people won’t come back to check the second beta.

• Don’t release meaningless software
Solve at least one users’ problem. Choosing problems which are real helps much. You can generate a lot of buzz with being just cool, but folks won’t stick with the app. I keep coming back to Google Docs and Spreadsheets despite their (still) poor functionality because they solve a problem of as-easy-as-possible documents sharing. I keep coming back to discontinued Google Notebook because it’s the easiest way to group a bunch of hard copies of website pieces. Solve one yet unsolved problem and I’ll keep coming back to you because I’m too lazy to look for another, possibly better, solution.

• Don’t ignore people with worse hardware than yours
Think how a web application would look on low-resolution screens such as netbooks or mobile phones. I wrote about importance of optimizing your website for mobile phones a couple of years ago and guess what: people didn’t stop using their mobiles to browse the web. They’re browsing the web with their phones like crazy. And in the meantime the whole new market of computers with screens worse than good old 1024×768 emerged.

• Don’t overlook boring features just because they’re boring
If the most basic functionality is screwed nothing is going to rescue you. If your application sucks as displaying characters users type on keyboard you shouldn’t really bother about introductory video or widgets your app can have.

• Don’t forget about branding
A big name helps. If your company happen to be named Google, Amazon, Microsoft or such people will use your shit no matter what. You won’t hurt of a bunch of rants on your new product since that’s pretty much expected. On the other hand if no one ever heard about your organization you don’t want people to learn about you from a rant which is on the top of search results. If that’s how you start with your branding it may be a bit harder to draw other users.

Yes, I’m aware I sound so old-school and so boring. Feel free to ignore me as I’m not a typical early adopter. But don’t cry when people stop coming back after a couple of visits. And yes, you have their emails in your database but the only business you can make on that is selling them to some spammer since people aren’t going to give you next chance.

What are differences between modern web application and good old thick client we used back than before internet bubble came?

One is responsiveness. Web applications generally suck when it comes to rapid response to user’s actions. Just today my friend told me how fast a time tracking app has become when he installed recently released Google Chrome add-on for Internet Explorer. If it wasn’t a web app he wouldn’t touch the application with that level of responsiveness. Not even with a stick.

What else? My call is usability. Web is still mouse-focused while most of old school thick clients are, or at least should be, keyboard-focused. The early web was all about navigating with mouse but that’s the old truth: keyboard is faster. The web should just mimic keyboard-driven navigation from thick clients, shouldn’t it?

Well, no. Not so fast. The problem is every web page works within some thick client – a web browser. Now, you can’t just use all these Alt+something or Ctrl+something since you don’t know which version of which browser your user launched.

Yes, Ctrl+O opens a file and Ctrl+S saves a file pretty much everywhere. But you don’t really know what Alt+N does in my Firefox and in my Internet Explorer. And as far as shortcut isn’t intercepted by the browser it will be passed to a web application. Unfortunately you can’t know when it is and when it isn’t.

The answer? I wish I had one which works every time but that’s not true. One great approach is the one used by Google Reader. They use characters and Shift+characters as their shortcuts. This doesn’t interfere with Alt+something or Ctrl+something used by browsers. Unfortunately this doesn’t work whenever you have a lot of text to be filled by the user since then you use letters and big letters to fill the text.

Another option? Leave shortcuts alone but make standard tab-pedaling as intuitive as possible.

Any other ideas how to solve the problem?

On a side note: a little hiatus here was connected with deployment of my private project. In other words: finally we have moved. There are glitches all over the place but the first service pack (term copyrighted by Szymon) is scheduled for the next year.

What’s your favorite tool to create a GUI design? Mine is whiteboard and a marker. Unfortunately it has some disadvantages. While windows and controls can be created rapidly whiteboard leaves you with pretty rough design. You don’t really think about specific positioning of all buttons and lists. You don’t think whether labels are fine or are they too long. You don’t think how a window changes when you display new controls. It’s all done when first working prototype is ready.

If you try to create clean GUI design you usually need some kind of tool for that. Usually IDE allows you to create clean sketch of GUI. A problem is that a person who should do the job rarely uses, and basically never needs other function of, IDE. That’s where MockupScreens appears.

MockupScreens is pretty light-weight application which allows you to prepare GUI design. You can prepare multiple screens using all basic controls and you can add some flow between these screens mapping actions (screen changing) with specific controls.

Strengths

Easy to use

MockupScreens is very easy to use. You need no documentation whatsoever to prepare your first design. You don’t have fancy controls at hand – just basic shapes, but that’s exactly what you need. You don’t try to polish your app – you’re building first version of your GUI. You definitely don’t need bells and whistles now. What you get instead is simplicity.

Gets the job done

It’s hard for me to get excited about this application. Building GUI sketches isn’t dramatically creative kind of task, you know. Anyway the big strength of MockupScreens is that it gets the job done. Not much more but nothing less than you’d need. Actually I always rant about lack of some features and this time somehow I don’t feel this urge. Strange.

Clickable prototype

A nice feature, especially for presentations, is you can create a usage flow of application you design mapping buttons on one screen with another. This way creating a clickable GUI prototype is very easy. This can bring you some ideas how you can improve your GUI. You can act like you heave working application with no development work whatsoever. Don’t show MockupScreens to your sales people.

Black and white screen mode

This feature was definitely proposed by one of the engineers. You can switch a design between desktop app, web app and black and white mode. The last one doesn’t try to imitate standard controls look but presents very basic design. This way business people wouldn’t think you have your app ready as they could think looking at clickable GUI prototype.

Weaknesses

Rendering speed

As you fill control options with data (labels, list elements etc) they’re automatically presented at your design screen. Unfortunately it’s slow. Oh so slow. It’s a bit frustrating when you try to fix a typo but actually a cursor is two characters after you.

Main editing area

I know I’m sick to work on 10,6 inch screen but this makes main editing area in MockupScreens pathetically small. There’s no rescaling feature either. This enforces heavy usage of both vertical and horizontal scrolls which I’m not very happy with. I guess this must be some kind of punishment or something.

Controls transparency

Controls which are used in MockupScreens aren’t transparent where there should be. It leads you to situations when you put frame on your screen and it hides everything which was there before. You can deal with it using Visio-like “bring back” and “bring forward” options but hey frame should be, well, just a frame.

Summary

Actually the best summary of a review is already written in the first two strengths – MockupScreens is easy to use and gets the job done. It’s a nice alternative for IDE features for all folks who aren’t developers and don’t need (and don’t want) Eclipse or Visual Studio installed on their machines.

As a test I created very simple design of one of web application we were recently working on and I have to say it was easier to present what I wanted to achieve with MockupScreens than with a drawing on a whiteboard. Basically what MockupScreens did was forcing me to put some order in my ideas how to arrange all controls and made me rethinking a bit whole GUI.

Having said that a whiteboard is still my favorite tool for GUI design but I’d go for MockupScreens whenever I need something more detailed with rather precise controls positioning. Using the tool is also a good idea whenever you talk with business people or a customer – they don’t necessarily have to appreciate your drawing (lack of) talent.

Test cases are here for a long time. Used equally willingly by these who work with heavy-weight processes and those who choose the agile way. They can be stored in an appendix to documentation in BDUF (Big Design Up Front) project or be written on yellow cards along with user stories. Where’s their main value then?

Think about the comparison: test cases for application functionality are the same as unit tests for application code. Except of one thing: it is way harder to write good and complete list of test cases. You may safely assume that’s impossible. This means the main value of test cases isn’t in covering full application functionality because you simply won’t achieve that, no matter how hard you try.

Well, maybe it is a valuable tool for QA engineers? You know, they have some kind of walkthrough for testing sessions. Hm… show me quality engineers who prefer just to follow test cases instead of explore the application by themselves and I’ll tell who should be fired. Testing is such a creative task that there should be no place for follow-the-manual people in QA teams.

OK, test cases don’t ensure completeness of tests and don’t help QA people much. So? Show me the money, as one of my customers used to say. Where’s value?

The main benefit of test cases lies in the activity of writing them down. Or, to be more precise, in the process of thinking about them before they’re written down.

Test case is not much more than short scenario of application usage. Sometimes pretty weird scenario but still. Unfortunately we often forget about this perspective. We tend think in terms of code or requirements and forget about the very basic thing – no class in the code and no requirement alone makes any sense for the end-user.

Looking at application while being in end-user’s shoes benefits in two ways:

- You find black holes of your design which aren’t covered with user stories, or requirements

- You find usability issues since you see whole usage flow, not just a bunch of atomic functions

The main value of writing unit tests is actually within the writing part.

We’ve just started a new project. We are at the very beginning and we still don’t work under pressure of time. And that’s great. Such slow start is a chance. A chance to set things up as you would like them to see in ideal world.

We use this chance to:

• Choose and verify tools used during development. Continuous build, unit testing, static code analysis, coding standards – all this things which should be on place but so often there isn’t enough time or you have to throw everything away because of some emergency. And if you try to do it in already settled environment it’s such a painful and long process.

• Design properly. Have you been in a situation when you just do your wild-ass guesses (aka rough early estimates) and suddenly you have to start coding because you’re a month behind a schedule before even a contract was signed? It is said that testing is the first place where you (unwisely) cut schedules. Well, designing holds a strong second position.

• Find time to discuss requirements. Is all clear? Yes? Good. Write it down. Go at least one level deeper to get more details. Another time write it down. Now, get people read it and understand it. Are there any questions? Of course there are. Congratulations, you’ve just eliminated some issues which would appear later and would be way more painful.

• Adjust project management techniques. Ensure you gather all the data which will point how much you miss initial estimates. Set workflow for work items which won’t be a pain in the ass for developers. Think what people pointed as problems during last post mortem session – do you always find time to use this knowledge to improve your projects?

Basically all these things are just simple ways to avoid or limit technical debt. If you start slow it’s much easier to set them up properly which soon will return in terms of team general productivity. Of course that does mean additional work if you compare it to impossible-to-meet ideal world schedule where everyone produces best of breed results with highest possible performance.

The reality is that projects with technical debt starts producing visible results faster but they soon lost their advantage and over time are more costly. Starting a project slow gives you an excuse to do a good job in this area. You can need one for your bosses and you can need one for yourself.

I installed Visual Studio recently. Not that I plan to get back to programming but I needed a client for Team Foundation Server and web client unfortunately doesn’t support all needed functions.

I must admit guys from Visual Studio check whether display resolution is suitable to for the application. A plus for them. During installation I got the message:

“Visual Studio 2008 is designed for a minimum resolution of 800 x 600. Although Visual Studio operates at a lower resolution, you should set your display resolution to 800 x 600 before running Setup.”

800 x 600? Um, wrong. Rather 1024 x 576. Can’t set it the way you want. The funny thing is they check display resolution but they come up with wrong conclusions. A minus.

Anyway so far I see no problem with not sufficient vertical resolution while working with Visual Studio. I guess the only potential problem is within horizontal resolution since there would appear horizontal scrollbar (which always sucks) or something. A big plus.

Overall my impression is positive. Actually Microsoft (except of Live Messenger) does pretty good job when it comes to minimal application resolution.