Web Dev Best Practice

Even if most new applications are built with the web in mind, there are still .NET applications out there. And they will continue to be, although many limits of web applications fell in the last years, like WebGL.

For web applications, it's easy to provide a way to get feedback from your users directly.

Until now, having a similar experience for desktop .NET applications was not possible.

Check out this new SDK which allows developers to get In-Application bug reports directly on the touch of a button:

No longer "it does not work" bug reports via email without the context. What I really like is that you'll get a full screenshot of the application and it's even possible to add meta data like the used Windows version, .NET framework or exact build number of your software.

Don't let your users choose what they tell you.

And I really wasted my time to explain Snagit to my end users, ending up with a stamp sized screenshot which does not explain anything at all, like:

"Make the number larger". But where?

Many people are too busy to improve their web development process - or at least, they seem to be too busy:

(Image credits dcode)

Let's talk numbers

When is improving no longer optional and a must? I think when a process can be made double as efficient as it is right now.

Josef Trauner conducted a study how long it takes for three standard web development issues to communicate, reproduce and fix. He compared the following three techniques:

plain email communication

using a desktop screenshot tool and upload the image manually to a bug tracking tool

streamline the process with Usersnap

The three bugs (which can applied to nearly every web project) were:

"Move the logo from the top to the bottom" inside an app

"Where is the CVV field for the credit card?" in a checkout form

"I can't read the states entry" - failed RWD

The cost for the total time needed to fix those three bugs, including communication and development time) compares as follows for the three methods. Download the free e-book to find out more!

The cost transforms into the following savings, per ticket! Establishing this new process would give you more than 8 man-hours a week per developer back!

I don't know how many users would actually create a bug report if they find something which does not work properly on a site. Perhaps only a few percent if you might think about a huge page like Wikipedia.

In my opinion, the remaining percent which is willing to report a bug should be honored and at least given the chance to do so.

Imagine you find a bug on Wikipedia itself. You decide to report it and search for "how to report a bug on wikipedia". You will find a full how to which is about 3 pages long: Wikipedia: Bug reports and feature requests.

You are still convinced that your bug is noteworthy, so you go on to register on their Bugzilla and open the Create a new bug in Bugzilla form:

Woah! Look at all those fields. Well, perhaps I better not report my issue - don't have time for this complex form.

Conclusion

My guess: only 1% of the visitors even tend to report a bug, but from those users many many get scared off by the utterly complex and formal process to report a bug. Important catch: the 99% just go away and are unsatisfied.

Is there something better?

Most of the improvements I tend to report are layout glitches or feature requests like "It would be great if I can sort this table here". But I definitely would not fill out a form like the one above for such a "feature idea".

Give your users a real simple solution to report bugs - you will see how fast your product will improve then. Usersnap is a feedback widget which creates full bug reports and fills out all the boring details (Browser version, Screen resolution, URL, operating system, installed plugins, yada yada).

Today, Kanban is not only a term in production or logistics. While invented in the early 1950's by Toyota, it's more and more implemented by agile software development teams over the world.

Basics of Kanban (you can skip it if you already know Kanban)

The Kanban JIT method takes place on a real, physical kanban table. That's one part which can be seen as not optimal for distributed teams which are often the norm in modern startups. Many tools evolved solving this specific issue, some to name: Trello, Kanbanize, Kanban Tool or the beatiful Blossom. This is just a short excerpt as the market is really crowded and there are hundreds of tools out there waiting for your team :-)

The basic principle of Kanban is to have a limited amount of colums (in the example image below: Requested, In Progress, Done) with a limited amount of so called cards (like the entry "Toggle admin view" in the Done column). The cards travel from one column to the next (or to the previous, if they fail).

How to apply Kanban to Software / Web Development

Let's start with an example. You are in the middle of an project - a shop system for cat tracking devices (There is no such thing you say? It is: Tractive).

Imagine your customer wants to change the main headline.

You will get a mail / phone call: "Please change the headline".

You create a card in the column Requested and probably add some more details for your developers (like that the font size should be reduced)

During your next iteration the card will be placed in the In Progress column, the text will be changed and probably verified by your customer.

Everything is ready. The card is in the Done column and you can enjoy a cold beverage!

Not that complicated, you say? What if you forget to write the information into the card on which page the headline should be changed? In this case, developers need to ask you and the communication loop starts.

Solve the Problem with Screenshots in your Kanban Cards

Next time your customer calls about any change, prepare a screenshot of the situation and attach it to the Kanban card. Everyone now knows which issue needs to be fixed right away.

This card is concise and easy to fix now - have a look how it looks in Trello:

"Sounds like a lot of work to do. Creating a screenshot, annotating the issue, creating a card, writing the card, attaching the screenshot. I'll be better off with a call." 

Yes. It's more work to do, but you don't need to do this for yourself. There are tools which automatically create cards with screenshots in your Kanban software - check out Usersnap, it supports over 20 different tools.

What to add to your cards next?

The more you think about it - nearly every tool can be used as a bug tracking tool - huge email threads, Excel sheets or even shared text files in Dropbox. In fact everything is a matter of execution and management.

My minimal set of bug tracking features which make a tool useful contains:

Status: Open / Closed (Checkbox)

(segmented) Lists (by user, by category, ...)

Owners and Assignee

Comments

A unique, rememberable Ticket/Task number

Sorting of Tasks / Filters

To really work with such a bug tracker, the following extended features can improve your workflow even more:

Due Dates

Milestones

Labels

I doubt one can work with a wiki in an useful way for bug tracking. Have a look at the myriad of existing bug trackers / project management tools, just a few to name:

Trac

Redmine

Basecamp

JIRA

Axosoft

Usersnap

The better question is: How can I add proper bug reports? In my opinion, the visual way is king here - as it's always easier to show, instead of telling something.

1. USE A BUG TRACKER

The inbox of a Head of Development tends to fill up over the day with feature requests, bug reports and snippets of user feedback. Sometimes you’ll even receive emails with a whole bullet point list (if you’re lucky) of requirements, pain points and random ideas. While it’s great that people take the time to give – at times very extended – feedback, it’s not really useful as is.

Using a bug tracker / project management solution like Basecamp or Trac you can reorder tickets and nothing gets lost, as tasks are only closed when they are done. Set a milestone, add keywords (so your co-workers can find your ticket easily), add a priority level and make sure to cc the person in charge of ‘fixing it’. Even if that’s yours truly. In the description, try to provide a user story. And make sure your summary is descriptive, you can use humor for your commit messages if you really have to (i.e.: when it’s done), but you’ll want your ticket to be clear.

2. TAKE RESPONSIBILITY

Be precise and targeted. You should know who can do what and who is available for an additional task. When in real doubt about who’s responsible, you can do a CC. But make sure to remove all others from the CC, as soon as you found the right person to assign the ticket to.

3. ALWAYS KEEP OPTIMIZING

It’s important to always think about ways how to optimize your application. Let me share my boilerplate – three steps to ultimate development success – with you:

Make it work.

Make it right / beautiful.

Make it fast.

Keep to the order of this list and you will get sustainable results. Plus: you are sure that your optimizing bases on working and correct code, not a work in progress code heap.

Enough?

In general, I don’t like to focus on the negative, but just this once I'll sum up the top three bad habits in web development (or development in general). 

1. MAILS WITH 20 BULLET POINTS

Mails with 20 bullet points, listing bugs, feature request and what not, are as much a commodity as a problem.

Often they lead to accusations and “why didn’t you fix $XY, as I pointed out five weeks ago?”-s. In case your head of development is not able to drill these monologues down to workable tickets, chances are you forget things. Instead of muttering all kinds of things your mother didn’t teach you, try and educate your clients or managers how to use a bug tracker or project management tool.

That way you both save time sending countless lengthy emails, and they’ll have a better view of what you’re currently working on.

2. CC’ING THE WHOLE TEAM

CC’ing all means: you have no idea who can solve this task. Which is bad in itself. If you start doing this, potentially no one will answer or feel responsible. Plus: reading all those mails will kill a lot of precious time for those who are not into it. Find out who is responsible and address that person only.

3. LEAVE TESTING TO SOMEONE ELSE

Letting somebody test issues who has no idea what the original error was, is yet another way of wasting your team mates time.

Example: a customer complains about buttons not working in Internet Explorer. The first dev that gets his hands on it fixes the issue, and another one QA tests it without even knowing how to reproduce the issue.

You'll find yourself like this lady:

http://devopsreactions.tumblr.com/post/52368854242/writing-unit-tests

SUMMARY

Create feature teams, that means:

a whole team works on a feature, and not on “the backend” or “the frontend”.

I’ve heard from this idea the first time in Budapest from a friendly Yammer developer. They pushed this to the max which means: even fixing bugs is a feature team and those are rotated often. This means, everyone has to be prepared to fix other’s bugs, but, notably: not their own. A great idea for building great software.

Some discussions with my clients look exactly like this in my inbox:

Content of the discussion:

A: "Please fix the button, it does not work".

B: "Which button?"

A: "The blue one"

B: "There are five blue buttons"

A: "I only see four"

B: "So which one do you think of?"

...

(In the end it turned out, that a rare Internet Explorer bug caused one button to disappear...)

This could have been way easier. Imagine the customer can show you what's not working with a bug reporting widget. It's a win-win situation. You'll get a bug report with meaningful information and it's even faster than creating a screenshot, copy & pasting it into word, wrapping it into Powerpoint and sending it via email ;-).

Adding such a widget (I can recommend Usersnap) is very easy. Most websites re-use files for common content (so called template files), so it's very likely that you won't have to place the widget on every single page. This help page wraps the process up in a few lines.

Once your customer sends the bug report you'll get it presented in a dashboard and can immediately start to fix it. Next to the screenshot you'll find useful information like the screen size, browser version or even a list of plugins! Nice :-)

Identify users which really use your service. Those gave your service a chance, even if it's not perfect yet. Get in touch with them directly and ask them if they will do you a favor on improving your product. Once they are in your email loop, many ideas will pop up. Make sure to filter those ideas, as in the end you should be in charge of the product development direction.

If you are lucky and you'll get improvement suggestions, please ask your interview users for screenshots to make sure you know who is talking about what. Usersnap is a great tool to get feedback at this stage. It's useful for internal QA and product discussion, too.

When it comes to quality assurance, developers in remote timezones (read: you only have about 2 hours overlap per day) can be a real pain.

Imagine testing a feature, creating a bug report and only the moment you leave the office your remote developer needs informations from you to reproduce the bug (e.g. the exact browser version or the URL of the error). Losing days in the release schedule is not uncommon here.

Ideally, your remote developers get proper bug reports with all the information they need (browser version, URL, a proper screenshot, installed plugins, ...). Make sure that everyone on the team can create meaningful bug reports.

At Usersnap we are a distributed team and we found a solution to boost your remote team efficiency.

Usersnap is a small feedback widget which creates a screenshot with proper bug information and annotations of the user. We created Usersnap just to solve the communication problem in web development, which happens remote even more often.

Communication in web development is often quite complicated. You are a probable a remote team, but even more important: you are an interdisciplinary team.

Given that, communication is key. Not every bug which is a no-brainer for devs is easy to communicate (e.g. why a specific button is only enabled after a number has been entered in a form). And: not every simple change is really a no-brainer to fix (can you move the checkout button to another page?).

One could say: "Designers are from Venus, developers from Mars."

Saving time in this communication (be it for feature requests, bug reports or just random ideas) is crucial in a remote startup, as losing a whole day is no rarity here.

Usersnap is a visual feedback tool which solves this Communication Problem for remote development teams. By adding a small feedback widget to your web project, all team members can create meaningful bug reports (including a screenshot with notes on it, the exact browser version, screen resolution and so on) which will definitely save time.

How do you collaborate in your startup?

I'm looking forward to your thougts.