Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 
Former Member

How to mock up the solution?

Getting started - mock up tools

First things first - what do I want the end product to look like?  I generally like to use mockups or wireframes of UI's as a starting point for my application builds, however I no longer have a license for Balsamiq Mockups that I have used for years so I needed to find something as a replacement, that is ideally a plugin for Google Chrome so I can access it on whichever PC I happen to be using.

A bit of searching in the Google App store for Chrome led me to a number of options (including Balsamiq) but most are trials, have bad reviews, are only for mobile, have rubbish functionality or all of the above.  I could probably spend months just researching the different options but for the sake of my sanity, and your time, I settled on NinjaMock.  It looked like it had the features I needed, appeared free (we will see...) and the reviews were generally positive.

Initial experience is good, as you get to choose the type of project you want to mock up (I went for iPad to begin with) and then you are presented with a pretty impressive set of tools for creating the various layouts for your application.  You can create 3 projects with the free version, which seemed more than enough for my current usage.

User stories

Just what do I want my solution to deliver?  I'm following a sort of pseudo-Agile-lite (could I market that as a great new methodology?!) approach for this so initially I've captured the features I want as a user - basically there is only my perspective as I'm the only user at the moment.  As this is more of a PoC than a fully resolved application, I'm not getting into too much detail here but just enough to convey the main features I want in my app.

  • I want the app to authenticate to Twitter via their OAuth mechanism so I can login and it will have access to my following and lists data
  • A table showing all lists owned by me, with ability to add/delete/edit the entries to manage my lists
    • Drill down from a list object to see members of that list (short-cut link to the table mentioned below, pre-filtered to one specific list)
    • Add/remove members of the currently displayed list
  • Table showing all users the current user follows
    • Cross-referenced with lists owned by the current user
      • Each row is a user - each column is a list
      • Check boxes in each cell to control if user is a member or not of the list
    • Headers (list names) static to allow scrolling and still be able to see the list name
    • Ability to show only users that aren't already in at least 1 list
    • Option to create new list from the main table - when performed, updates the table with the new list in a new column
Chicken or Egg?

As an aside, I often wonder in which order the mockups & user stories should be generated.

If you capture user stories/requirements first, you can guarantee they will change once mockups are presented - conversely if you present mockups first the user will remember extra requirements once they are signed off.

Ultimately, mockups should go hand in hand with requirements and be generated in parallel to ensure complete scope coverage.

This can of course make the early stages of development more involved and potentially needing more than one person to manage efficiently.

Mockup Flow

Using NinjaMock, I created a rough idea of how I think the screens should end up.  Of course, this isn't a particularly complicated application and so I didn't need to worry too much about stretching the UI5 library with simple buttons, tables and checkboxes.  In a more complex environment, I may need to be careful that the UI designed with my mockup tool is compatible with the library available in my UI technology, in this case UI5.

I ended up with this mockup application - called UTLS - UI5 Twitter List Sorterer - as a starter for 10.  It isn't fully resolved (or at least wasn't when this blog posting was written) and may very well evolve over time as my efforts continue.  I didn't want to spend too much time on this phase as it doesn't really help with my understanding of UI5 :smile:

I really like how you can share projects and your users/customers/peers/etc. can walk through the mockup in their browser - very cool.  Balsamiq had a great feature that generated a .pdf file with navigation built in so you could achieve the same thing, however you would then have to email it out.  I much prefer the Ninja way of doing things.

My UI has a very much Twitter standard look & feel to it.  I'm not looking to re-invent the wheel here, I am mainly using this solution as a vehicle for some more structured UI5 learning so I'm not losing too much sleep over how fancy my application looks (that might come with version 2.0!)

Mapping Features to Requirements

With the combination of user stories above and my initial mockups, I can now start to generate a list of actual requirements I need to build:

User story




Already Exists?

Authenticate with Twitter

Landing page


Main App container with simple template layout

Authenticate with Twitter

Log on link


Url control pointing at function to call OAuth

Authenticate with Twitter

Call Twitter OAuth

Business logic

Call the Twitter API and handle the request/response cycle, with suitable error/success messages

Authenticate with Twitter

Twitter OAuth


Remote API usage


View following counts and list counts

Display logged in user details


Show profile information, including following and list totals

View following counts and list counts

Get user details from Twitter API

Business Logic

Build call to Twitter API and parse results of user info

View following counts and list counts

Get user details from Twitter API


Remote API call


I've stopped here with the above extract as this table would quickly get very large (and boring) for any readers of this post.  Suffice to say, I've got an off-line version that holds more entries than this and is my master list of features I need to build.  For reference (and more stating the obvious) I tend to categorise features into the following rough buckets:

  • UI - something that is part of the user interface and typically maps to a View element in the MVC paradigm
    Ordinarily this is something that could/would be constrained by things like the UI libraries available, the customers design guidelines or look & feel requirements, etc.  I find it best to try and capture all parts of this puzzle, so instead of just saying "build a landing page", I would break it down so I capture the page, headers, footers, links, and any other content on that page.  It is a low level of granularity in terms of capturing requirements but again, I find it helps a lot once you get into build in anger.  This approach is also useful for identifying common components, that can be re-used within different views.
  • Service - typically maps to the Model in MVC and could be any type of data source or function, external or internal to the overall application
    Often, you may be using services that already exist, such as some of the Twitter API calls in this contrived example.  I still think it is beneficial to capture these requirements, as aside from ensuring you have complete coverage of the technical elements needed to make your application work it also allows you to resolve dependencies between components if/when necessary.
  • Business Logic - some sort of logic that acts on the UI input, does some "stuff" and maybe forwards output back to the UI, whilst interacting with the services.
    In short, a Controller. :wink:   Apologies for the amount of egg-sucking training in this post...

Normally, I'd break the tasks down in this manner as I'd be responsible for estimating, resourcing and planning the build across a team of differently skilled (and potentially dispersed) resources so I find it useful to bucket tasks together, as well as identifying dependencies across tasks.  You also get a feeling of what service links to which business logic and ultimately enables which UI features, so if you are doing releases of the solution via Agile or some similar approach, it is a bit easier to manage what will be delivered and when.  I'm sure lots of people with vastly more experience in this area will be chuckling at my rudimentary approach but it works for me.

User Story Mapping

Following on from the above, there is an interesting application of User Story Mapping that is outlined best (IMHO) in this article with accompanying powerpoint pack.  It is this kind of approach that I try to follow and for me, makes the most sense.  Of course, with most things like this YMMV - I'm sure I do things differently to most other people.

Wrap up

I've now got a (vague) idea of how I want my app to look and the sort of functionality I want to implement.  Next step is to start building, and getting the first release of a working application up and running on my local laptop.  As I alluded to in the opening post in this series, getting past the inertia of starting a project like this is often the hardest stage for me.  I envisage a little bit of procrastination and random button clicking in the coming weeks but hopefully I will end up building something soon.

Image sources

NinjaJeyhun PashayevFlickrAttribution-ShareAlike 2.0 Generic


UI5 & Twitter API - A Personal Challenge

UI5 & Twitter - Designing the Solution (this post)

Labels in this area