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.