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 storiesJust 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.
| 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 | Feature | Type | Details | Already Exists? |
Authenticate with Twitter | Landing page | UI | Main App container with simple template layout | |
Authenticate with Twitter | Log on link | UI | 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 | Service | Remote API usage | X |
View following counts and list counts | Display logged in user details | UI | 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 | Service | Remote API call | X |
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
| Image | Author | Link | License |
|---|---|---|---|
| Ninja | Jeyhun Pashayev | Flickr | Attribution-ShareAlike 2.0 Generic |
Links
UI5 & Twitter API - A Personal Challenge
UI5 & Twitter - Designing the Solution (this post)
- SAP Managed Tags:
9 Comments
