Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

The Default Use Case

You should have a default use case (or a small set of them). No matter what are you making – end-user product, public API, protocol spec, etc. The default use case is the most common thing that your users will do with your product. The focus of your product.

And after you define your default use case, you must make sure it is the most obvious and easy thing to do. Yes, this sounds like a very obvious and universal thing, but many products fail to recognize that.

Here are a few examples of products that do it right:

  • The default use case of google is searching. They make it pretty obvious – you have one text box and one button (well, two actually). It is the most straightforward thing to do with their interface. Of course that is not the only thing that you can do – you can customize your search, customize your language, you can advertise or visit their side-projects. But all these are options at the side of the screen. The default use case has all the focus
  • The default use case of Amazon is purchasing. Do they make it obvious? Yes – you pick your items and you click the 1-click checkout button. Extremely simple. And the most obvious thing to do. Of course you can customize all the steps in your purchase, you can be a seller yourself or you can write reviews to items, but these are “side-options” that are available if you look for them. But you immediately see the default use case, and it is the easiest thing to do on the site
  • With the Java collections framework you have two main steps of usage: fill the collection and then iterate the collection. Every novice programmer can create an ArrayList, fill it and then print its elements. And for many things this is all you do with a collection. Is it simple to do? Sure – collection.add() and the for-each loop. Are there other useful features? Tons of them. Synchronization, read-only views, search, different collection semantics, etc. But these options are usually not needed, so they are not part of the Collection interface, and they are not the first thing you learn about collections.

To prove that this is not obvious, let me give two examples of products not focusing on their default use case:

  • The other day I wanted to buy a ticket for a concert. The site that sold the tickets had 10 steps for purchasing a ticket, some of which included clicking on one of several links within a free text. The other links showed you more details about the concert hall, the price class of the ticket, and other information that is not required for the default use case. Which could be brought down to three steps – select the event, select a seat, pay. I bet they are losing tons of clients because they get lost in the UI. Because the site owners didn’t focus on their default use case at all.
  • The Java DOM API. This is a good example by Joshua Bloch. What would you normally want to do with a DOM API? 1. Parse documents and store them in memory 2. Create documents in memory and write them. How to do the latter? Here is how. You need a Transformer factory, a transformer, and two adapters – a DOMSource and a StreamResult. This is the least straightforward thing to do, and I won’t tell you how much time I had to spend to write that snippet of code. The API should have instead provided that “printDocument(..)” method.

It sounds simple, but it is very easy to overlook this important detail, and make a product that is tedious to use. So before you start, define your default use-case(s). And constantly verify that you are on track. This is for product managers, architects, project owners.

Am I telling the obvious? Yes, but note the generalization of “products”. Anything has a default use case – not only software. Even a cafeteria has it, and if you have to go through 6 steps to order a simple coffee, they will probably lose you as a customer. So whatever you do, be sure to focus on your default use case.

Reference: The Default Use Case from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog.

Related Articles :
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

Leave a Reply

three × = 9

Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

20,709 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books