Showing posts with label Requirements specification. Show all posts
Showing posts with label Requirements specification. Show all posts

Monday, 2 February 2015

Fluid, Responsive and Adaptive VS Fixed layout

In this blog post I present a way to decide on Fluid, Responsive and Adaptive VS Fixed layout. I have chosen to bulk Fluid, Responsive and Adaptive together because they are similar in that they adjust to the screen size, fixed layout does not. Fluid, Responsive and Adaptive layout are all different but for brevity I will call them Responsive below.

Most old websites have a fixed layout so many developers who are in the situation of giving a facelift to a legacy website often have to decide between Responsive VS Fixed layout.

The rise of Bootstrap and responsive layout with its extremely easy to use framework has certainly contributed to a many developers dropping their fixed layout.

I have observed how many web developers have just jumped on the bandwagon and adopted Bootstrap because it is just so darn easy. As an engineer I feel that many blindly go for Bootstrap or similar framework without much thought.
So below I give a more nuanced look into what to consider before redesigning an existing web application. The factors below have been picked especially for rich interactive social web applications rather than simple informational public homepages. I also assume you don't have unlimited resources so you are, as the rest of us, constrained to a limited development time.

Factors to consider

A - Esthetics.
B - Speed of user interaction.
C - Accessibility/ease of use.
D - Development time.
E - Screen size of users.
F - User browser maximized or not.
G - Mobile support.

All projects are different so you have to decide which of these factors are more important to you.

A: Do you want our application to look perfect with less cost? 
It is easier to make the site look good with fixed layout because layout often breaks with fluid layout. Images that users add to content areas don’t wrap as they expect on other screens. Headings added by users don’t wrap how they like on other computers. Background images can look weird etc.
If you have few resources and you want the app to look really good (on PC) you might want to steer towards fixed layout.

B: Do you have super users? 
How are users using the app? Are there mostly highly drilled users? Is it a Line of Business app where the business will measure the time users spend doing their work in the app? Do users have to be able to complete their tasks really quick?
By using more screen real estate users can perform actions faster and find information faster without having to scroll, use paging or navigate.
If you have requirements for being able to do lots of actions fast you may want to steer towards responsive layout since you are able to use more of the screen width.

C: Do you have to be particularly user friendly? 
Using more screen real estate will often lead to more “things” being visible on the screen. More things = higher cognitive load. For super users this is fine but for users who is not using the solution that often and for senior users this will reduce their user experience because they are simply overwhelmed by the content and options visible.
So who are you targeting? old people, beginners, non-computer literates.
Responsive design does not have to increase the amount of stuff on the screen but it usually does. A fixed layout is easier to learn as it always looks the same. If you by any chance did not maximize the browser window as you usually do you might get a different view than you are used to. For computer illiterate and infrequent users this can pose an issue. With a mobile first design approach, a max width and adaptive layout the UI can still look clean but this is not compatible with B above.
If you have requirements for being very user friendly you may want to steer towards fixed layout.

D: How much time do you have?
My initial starting point for this blog post was that you were about to decide to change from fixed to responsive layout so naturally you are in for more work if you decide to change. Also responsive layout requires more development and testing to check that it looks good on different screen sizes.
If you have little time you may want to steer towards fixed layout.

E: What's the typical screen size of your users?
If a significant percentage is using a screen that is smaller than the fixed layout width or they are using phones and tablets then you should definitely switch to responsive.  If users are having a screen size that is smaller than our fixed layout it will cause bad horizontal scroll bars or zooming that makes it very cumbersome to hit buttons etc.

F: Do users have their browser maximized? 
Could for example be because users need to keep multiple windows side by side etc for example when they need to copy content from another window and into the app.
In this case a responsive layout may work better.

G: Do you have to support mobile?
This is usually the one biggest concern that will decide it all. Is it a strategic goal that the app work well on mobile? Do you have plans to develop a separate mobile web app or even native mobile app? For many it is just too resource demanding to develop a separate mobile/native app so in this case you would go with responsive layout.


What are others using 

(Note that it is usually not a black or white choice. Most sites use a mix of techniques for example facebook is fixed but uses some adaptive techniques such as the chat and contacts feature on the right side)

Fluid/Adaptive/Responsive layout:

  • SharePoint
  • Jira (Confluence)

Fixed layout:

  • LinkedIn
  • Facebook
  • Yammer
  • Podio

Side note

Why does Wikipedia have fluid layout? Because all you do there is read articles. Ease of reading is extremely important there. With fluid layout the user has full control of the readability (line length etc) by resizing the browser window and adjusting browser font size.

Further reading


Tuesday, 14 January 2014

A simple requirements specification template for websites

If you are about to develop or hire someone to develop a new website you will need to articulate a set of requirements or needs for your coming website. In this blog post I will present a simple check list / template that can be used as a starting point. For more advanced high end sites you should go with a more in-depth process but the questions below might help you get started.

Visitor features

What should the visitors be able to do on this website? What kind of user interactions will the site have? Most importantly answer why. This should all be defined based on a content strategy / information strategy etc. What about multi-language support on content and the editor interface? What about features such as: contacts, events, press releases, product catalogue, webshop, automatic creation of PDF's such as reports, image gallery, videos, FAQ, user comments, forum, blog, wiki. Will there be specific needs concerning advanced content and design such as storytelling, copywriting, art direction etc.

Administration features

How will the website content be updated? Will there be any particular process for adding and modifying content? How many persons will be doing it, how often? How computer literate is this person who will be updating the content? Will you need to manage an online community associated with the website? In that case you might need a community manager, moderator etc.

Future site upgrades

Is it important that future developments to the site can be done by most development shops/consultants? If so state a requirement to use a commonly known CMS. Do we need any service level agreements for system changes to the site? Do we need support for the content editors? Do we need technical documentation on how the site is built? If there is a lot of advanced customization this might be a good idea.

Scalability

Is it highly likely that the site will become very popular within a few years? If so consider SaaS, PaaS, cloud services etc. to help you cope with dynamic traffic demands. This is also relevant if you know the site will have extreme traffic spikes at specific times of the year.

Site structure and content

Create a hierarchical view of the pages that will be part of the site. This can simply be a document with level headings going from heading 1 to 4. You probably also want to provide multiple ways to your content by using tags or categories? Will there be user generated content and what is the extent? Will there be massive amounts of content? What is your unique selling proposition (USP)? How will your site stand out?

Logging and audit trail

Is it important to log things like who did what when with site content?

Key Performance Indicators 

Will the persons responsible for the website be followed up on KPI's? E.g. maybe the web team is required to create a new post each week? or maybe there is a requirement that the site should have a certain number of visitors or be on a list of top sites within a specific category?

Visitor tracking and reporting

You probably need to visitor statistics. Is Google Analytics fine?

Search Engine Optimization (SEO)

How high are our ambitions when it comes to being found on and ranked high on search engines?

Accessibility

Should people with special needs be able to use the site? How much support should they get? Should they just be able to read it or should you provide good user experience for this group? Should blind people be able to use the site?
Where should the site be available? What kind of devices? Old devices/browsers?

Style

What kind of look, mood, style do we want? How do want to be perceived? Our values and mission has to fit the style. What level of design excellence should we strive for? Is it important that the readers find the site really good looking and appealing?

Security

Do we need special considerations when it comes to security and permission control? Will different people need different access to some content? Will some editors need more permissions than others?
Is it extremely important that the site is not hacked? Hackers typically break site and put advertising and malware on hacked websites.

Speed

Is it important that the site is fast to load? Do we need the site to scale? will there be millions of visitors and will the traffic grow?

Server location

What about hosting? How will the website be hosted? In your country? Maybe you have compliance rules to follow when it comes to where the server is located? Do we have environmental concerns? Some hosting providers are more environmental than others. If most of your users come from the other side of the world then consider a server location in that region.

Stability

Is it important that the site is available at specific times. Do we need disaster recovery and service continuity? Extra redundancy and backup plans in case of atomic bombs wiping out your country? a bit extreme there but you get the point.

Other requirements 

Non functional and functional? Maybe we are required to use Open Source? Will there be a need for related services such as video editing, brand/identity design, design of advertisement banners. What about e-mail accounts?

Contract 

Escrow? Budget? Time plan? Legal issues?

Wednesday, 23 June 2010

Requirements reminder

In smaller dev teams in some organizations, small projects often start without much consideration to requirements other than some design sketches. This is a starting point that can lead to several issues down the line, and it is typical when there are no solution architects involved. Once the team (or single developer) has chosen a technical path it might be very expensive to redo the system. The longer the system has been in use by end users the harder it is to rearchitect it.
In this blog post I list typical areas of IT systems. The purpose of this list is to trigger deliberation that can help you formulate a simple requirements specification. 
  • Access (Who should have access)
  • Accessibility, WAI
  • Accuracy
  • Adaptability
  • Audit and control
  • Availability (Service level agreement, downtime)
  • Backup
  • Branding
  • Browser support, clients
  • Capacity
  • Certification
  • Compatibility
  • Compliance
  • Completeness
  • Configuration management
  • Configure-ability (can it be reconfigured)
  • Correctness (no bugs)
  • Cultural and political
  • Currency (data is up to date)
  • Data structures
  • Dependency on other parties
  • Dependability
  • Deployment (deployment procedures, life cycle turn around and velocity)
  • Design (and layout)
  • Disaster recovery
  • Documentation
  • Editorial, publishing
  • Efficiency (resource consumption IT, energy, human, performance vs effort)
  • Emotional factors (fun, absorbing)
  • Environmental tolerance
  • Escrow
  • Error tolerance (wrong user input)
  • Error messages. (how and where)
  • Ethical considerations
  • Extensibility (adding features, upgrades)
  • Failure management
  • Failure tolerance (defect in system execution)
  • Install-ability (easy to install?)
  • Internationalization (e.g., different countries, languages)
  • Interoperability (properly interfaced with and working together with something else)
  • Language (style of writing, target group)
  • Learnability (easy to learn)
  • Legal (licensing issues, patents-infringement-avoidability)
  • Logging
  • Logistics
  • Maintainability
  • Memorability (easy to remember how to do thing in the system)
  • Mobility (Can it be used on the move)
  • Modifiability
  • Multi user scenarios (collaboration, access to the same objects at the same time etc).
  • Network topology
  • Open source
  • Operational , manual procedures
  • Operability (possible to perform tasks in accordance with operations manual?)
  • Packaging
  • Performance / response time (performance engineering)
  • Personalization (personal user experience)
  • Performance (Jitter, Response time, Latency)
  • Personell (and resources)
  • Platform compatibility
  • Portability
  • Precision of data
  • Price
  • Privacy (GDPR)
  • Provisions
  • Protocols
  • Quality (faults delivered or fixed)
  • Reuse-ability
  • Recovery (e.g. mean time to recovery - MTTR)
  • Reliability (e.g. mean time between failures - MTBF)
  • Reporting
  • Resilience
  • Resource constraints (processor speed, memory, disk space, network bandwidth)
  • Response time
  • Reliability (operates without failure under specified use)
  • Robustness (also functions under abnormal conditions)
  • Roles (Who can add, edit, delete, view)
  • Safety (preventing / dealing with accidental harm)
  • Scalability (horizontal, vertical)
  • Schedule-ability
  • Scope
  • Security (tolerance against malicious harm)
  • Source code
  • Stability
  • Subset-ability (easy to make different functionality subsets)
  • Support (end user support)
  • Survivability (essential services continue in spite of accidental or malicious harm)
  • Style
  • Templates
  • Testability
  • Throughput
  • Traceability
  • Training
  • Transportability (possible to move system)
  • Unambiguity
  • Usability (ease of use)
  • Usefulness (useful to use)
  • User experience (system perceived as fun, satisfying, enjoyable, entertaining, helpful, motivating, aesthetically pleasing, emotionally fulfilling, rewarding and supportive of creativity etc)
  • Validation (of user inputs)
  • Verifiability
  • Variability (degree to which different variants exist)
  • Withdraw-ability (can a specific version be withdrawn and replaced with a previous, version)
  • Workflow
  • Workload (low perceived workload by user)

References