Mobile Web – Consider the Purpose, then Design

Indian students using mobile - flickr

credit - helpingmedia

Trying to keep up and learn new mobile web design principles and frameworks is getting harder to do. Since last year, I have been doing quite a bit of research on mobile web for my work and for personal curiosity. Yet, I know I still have a long way to fully understanding what and how to properly go about approaching mobile web development.  There are many articles discussing design and development principles like adaptive, responsive web design, progressive enhancements, mobile first, and server side vs. client side adaptations.  Frameworks to develop upon are introduced from time to time as well.  A framework I am very familiar with is the UCLA Mobile Web Framework (MWF)  used by multiple University of California campuses including UC Los Angeles, UC Berkeley, UC San Francisco and UC San Diego. New ideas will undoubtedly come out in the next few months.  Questions I have had to think about and discussed with colleagues include “Should we have one site that can be displayed several ways depending on the device?”,  “Should we have separate desktop and mobile websites?” or “Are we also developing native apps?” I have quite a list of resources if you’re interested. I have tried to read, learn and experiment including creating a prototype site but it’s been a dizzying experience.

In my discussion with colleagues, what I realized was that to even have any productive/intelligent discussions about designs, those developing mobile web sites must understand two things: 1) Purpose of the site and 2) How to build and support it. With regards to the purpose, just like any software development projects, these requirement questions must be asked:

  • Who are the users and what do they want/need the mobile app for (use cases)? Here are a couple of examples:
    • Prospective students may use the site to check their application status, do some casual research about the university. If they are visiting the university, they may use maps on their mobile devices to get directions or phone numbers.
    • Current students may use the site to quickly look at their class schedules or browse events that are happening on campus.

Given these examples, developing for mobile devices should go beyond the presentation layer. Information architecture, the content to include and how to present the content should all be considered.  Presenting the same information on your current website represented in a different way may not be the most optimal for the users.

  • How will they be using the site (environment, equipment) ?

This question leads to the context of their use and what they will be using to access/interact with. I think the concept of mobile users as “always on the move” is probably not an accurate one. I, myself use either my iphone, ipad or droid while I’m on the couch watching tv or just before I go to bed. It also leads to examining what mobile devices can offer relative to desktop computers. For example, with mobile devices, there’s geo-location capability which means a user can potentially use a device for directions. Another consideration are the types of input which include voice, motion and gestures, pictures (qr codes, bar codes). While I’ve come across articles about how mobile devices have limited functionality due to their smaller screen size and media not supported (flash), I see mobile devices are just different mediums in some cases offering more than what desktops can. However, it is true that consumers should not have to be subjected to downloading huge images in terms of size and dimensions, complex layouts and  pages that users must scroll through several times to read. They should also not have to go through 50 links before they even get to the link they’re intending to use.  Accessibility, in addition, should not be an afterthought as well.

How and what types of mobile apps (web, native apps) to build and support are additional questions to ask before developing. In an ideal world where resources, talent, and budget are infinite, we could build and support multiple variations to optimize the user experience. However, reality dictates that we must consider what our organizations are willing and able to develop and support.  If existing frameworks we can leverage on exist, do we need to be building our own? We must also consider the constraints in place including technical and non-technical factors.  For example, if an organization is to provide mobile interface for an existing legacy system such as a vendor ERP solution, does the architecture allow connectivity to the data source outside of the vendor code. Another example are with home-grown legacy systems who may have been written a few years ago, including web sites with code that were not developed for today’s mobile technologies. Is it better to retrofit the site or create a new one instead?

Ultimately, the right approach to building mobile websites will depend on what the requirements are and what organizations are able and willing to build and support. In choosing to implement which certain design principles and what framework(s) to use, mobile web providers must seriously consider spending time and effort towards examining the purpose of the site and who the users are to guide the development/design process.

Am I thinking about mobile web design properly? What other considerations should I be thinking?

3 thoughts on “Mobile Web – Consider the Purpose, then Design

  1. Pingback: mobile helper,webdesiner,

  2. Pingback: Student Affairs as Social Business | Joe Sabado - Student Affairs Technology Leadership Joe Sabado – Student Affairs Technology Leadership

  3. Pingback: My Perspective on IT Leadership for 2012 | Joe Sabado - Student Affairs Technology Leadership Joe Sabado – Student Affairs Technology Leadership

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>