My thoughts on mobile webdesign

Around 2 years ago, I decided I wanted to play around a bit with mobile designs for websites. I also had a practical use case; I would use an API provided by our monitoring solution and hack together a mobile site that I could use to quickly (and with low bandwidth) check the state of our servers, see graphs, etc. As a bonus, it would allow me to easily acknowledge events that I know don't really matter at that time. This helps a lot when it happens at 4 o'clock during the night. And so, MoZBX was born.

You just need bigger buttons, right?

My though back then was: mobile websites? That's just the same as any other site, but with bigger buttons. You know, fat finger touching etc. Take a normal button, multiply it by x2, and done. You have a mobile site.

So with that in mind, I built the very first version of MoZBX using jQTouch, which back then was a combination of jQuery and some mobile enhancements (they now offer Zepto.js as well instead of jQuery, which seems to speeds it all up instead of the slow monster that I experienced jQuery to be on mobile devices). It was relatively easy to get a first prototype up and running, but it annoyed me. You see, I'm mostly a backend developer. I don't care about designs, I care about functional PHP code. I love to hack my solutions together in my own way and not have to follow rules other tools force me to use. I like my freedom.

That's when my frustration with jQTouch began: you needed certain ways of structuring your data, you need to follow strict rules on how to create forms, lists, styles, ... (with annoying submit-actions on forms, what's up with that jQTouch?), everything is being loaded via AJAX which makes UI testing a pain, ... It pulled the joy of creating a new project right out of me. MoZBX worked, but I wasn't happy with it. Windows Phone users couldn't access it, BlackBerry support was ... well ... a joke, ... I needed something else.

So I looked at other solutions, such as jQuery Mobile, Kendo UI, ... but none suited my needs. The reason I looked at those 'Mobile Frameworks' in the first place is my absolute lack of design skills, both in graphics and in CSS-styles.

Bootstrap FTW!

And then, out of the blue, came Twitter Bootstrap, which I shall name "a backend developer's wet dream for creating decent looking websites" from now on. So, trying to be hip and cool, I redid the UI for MoZBX in Twitter Bootstrap and threw away everything that was ever related to jQTouch. And there was much joy.

It took me a few evenings of work to test how Twitter Bootstrap worked, how I could use it in MoZBX and what would be the best way to get started. And a few days later, the new MoZBX was born.

Sites vs Native App

My conclusion so far is: throw away all those mobile frameworks you use if you want a mobile website. If you want those App-like feelings with swipe effects and page transitions, build an app instead. If you want a mobile site (see: it's even in the words, you're building a website, not an app), use plain old HTML and CSS for a responsive website. Stop hogging mobile UI's with frameworks that are overly complex and add overhead to each page request -- let alone the development overhead of adjusting the app to fit into that particular framework.

Granted, in 6 months, every website will look like it's been made with Twitter Bootstrap, but I don't blame them -- it's easy to use and it just works. No need to dabble in new 'frameworks' to get your mobile site going. Use CSS and HTML, create bigger buttons, and you've got yourself a mobile site.

Side note: if you're a graphics designer working on a mobile website for the last 6 months, I apologize for the overly simplified statement of 'mobile just means bigger buttons'. I do appreciate all the work you put into creating beautiful pages. For me however (and in particular, this monitoring project), it's overkill. I just needed bigger buttons.

One comment on “My thoughts on mobile webdesign
  1. .wu says:

    one thing – compare mobile stackoverflow with regular one :)

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>

Advertisement

Why ads?

I'm glad you made it to this blogpost. I hope it helps solve your problem. So why then do I show ads on the site? Writing content, testing it and making sure the layout isn't totally b0rked takes time. A lot of time. The ads are a way to pay back a small portion of that time.

And as you know running a site costs (a bit of) money: the domain name, webhosting, time spent writing and updating content, ... So if you like the content of this blog, consider disabling your AdBlocker for this domain. Thanks!

Recent posts

Looking for help?

Tired of fixing all these tech-problems yourself? We've got an excellent team at Nucleus, a top-class Belgian hosting provider, that can help you.

Discover our Managed Hosting, where skilled engineers manage your servers and keep them up-to-date, so you can focus on your core business. We use a variety of Configuration Management Systems such as Puppet to make sure every config is reviewed, unit-tested and guaranteed to be working.

Want to get in touch? Find me as @mattiasgeniar on Twitter or via the contact-page on this blog.