Skip to Content
Author's profile photo Former Member

UI5 & Twitter – Designing the Solution

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 Sortereras 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 🙂

Ninja.jpgI 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. 😉   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

Image Author Link License
Ninja Jeyhun Pashayev Flickr Attribution-ShareAlike 2.0 Generic


UI5 & Twitter API – A Personal Challenge

UI5 & Twitter – Designing the Solution (this post)

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Robin Van Het Hof
      Robin Van Het Hof

      Hi Gareth,

      Nice blog, and thanks for pointing out NinjaMock -- although I'm an avid Balsamiq user this looks very tempting.

      I tend to think breaking up the tasks into categories of logical components is something that is easily forgotten, but really helps to keep track of to do's and dependencies

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Thanks Robin.

      Like you, I've been a user of Balsamiq for a good few years now, and may well come back to it in the future but for now, I'm giving NinjaMock a try.  They appear very, very similar so far so its pretty easy to use.

      I'm not the most organised so anything that helps with managing dependancies is good in my book 😉



      Author's profile photo Kenton Hankins
      Kenton Hankins

      You should try Axure its very robust and can even mimic responsive designs. You can go from sketch like designs to wireframes to full fidelity very highly interactive prototypes.  They even will host your mockups for free on AxShare.

      Author's profile photo Jason Moors
      Jason Moors

      Axure is good, a lot of the design agencies I've worked with use it, however it's not cheap, $300 for standard version.

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Axure does indeed look like a quality product but I'd typically discount it for a few reasons:

      • Cost is a big factor - I might be able to convince my boss to buy me it but if i want to make best use of it with various customers, I'd prefer them to have their own copy too and the $300 makes that difficult
      • It looks "too good" - I like Balsamaiq and now NinjaMock as they are pretty simple and not too involved.  The danger with something that has all the bells and whistles is that you spend too much time refining the mock-ups and polishing their look and feel, which could be better spent on the real solution.

      Just my thoughts. 🙂



      Author's profile photo Robin Van Het Hof
      Robin Van Het Hof

      Not only that, but working with bare-bones designs created with Balsamiq and NinjaMock lets people focus more on functionality, UI and usability, and immediately takes away the urge to comment on colors, shapes and pixel-imperfectness

      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Completely agree Robin - nothing more frustrating than losing a UI workshop arguing over the colour of a header and the size of a button!

      Author's profile photo Jason Moors
      Jason Moors

      I agree, wireframes are good for discussing functionality, however I find myself spendig less time on complex wireframes and designing more in the browser, with SAPUI5 project templates and snippets it's becoming very quick to pull together a real mockup.

      Especially with responsive designs, it's quicker to show in the browser than create high fidelity wireframes.



      Author's profile photo Kenton Hankins
      Kenton Hankins

      Everyone's comments are pointing to a good user experience process, which is one of the reasons I prefer Axure. The SAP community is recently starting to understand and embrace a user experience process, while many successful companies outside SAP have been doing so for years. 'Design Thinking' is nothing more than a flavor of a user experience process cleverly wrapped up in marketing.  If that marketing gets more people thinking about user experience that is awesome.  So why do I prefer Axure and why has my company along with some of the big players (Accenture) use it so heavily?

      - Process Enabler: At my company we have a project template that outlines a good user experience process we put literally everything in Axure.  From personas to mockups to timelines.  You can start with just place holders in your prototypes then move on to features and eventually full on color.  We like to keep all 3 versions in the same Axure file then we can show the client the progression from ideas to full fledged UI mockups.  On more than one occasions I have created interactive mockups with content in only black and white this takes those rather tiresome color conversations out of the picture.  If you design can not hold its on in black in white generally adding color will not fix your problems (with some exceptions).  I highly encourage everyone to try that on their next design.

      -Features: It has tons of features and can even be hacked to increase its functionality.  The specification generation is just flat out amazing when used properly.  You can start with placeholders and have no UI then transform to a full on high fidelity mockup.  Now you can even create responsive prototypes

      -Easy to learn: The learning curve for basic features is very gentle you can become very proficient in minutes.

      - Cost: While $300 might be a little pricey for some, iRise a competitor is 10X the cost.   There are certainly some less pricey alternatives (Balasamiq - which I think is a good tool), however another competitor Just In Time has a pay as you go model which cost $19 a month or $228 a year.

      - Team: You can have multiple people work on the same prototype

      - Community: Axure has a very large and active community with forums and plugins available