For a little over a year now, I’ve worked in the portion of web development that focuses on mobile devices. That doesn’t mean I get to completely ignore larger display devices all the time, but being in a mobile centric workflow has broadened my planning scope to adapt to unforseen, unpredicted, and unknown display ranges. Very few, if any of us, know what is being invented in some random nerd’s mom’s basement that will change web access as we know it. Such being the case, I’m a strong believer in the Adaptive Web Design, Responsive Web Design, and Mobile First philosophies.
I prefer to build things with fluid layouts and flexible grids. I make extensive use of media queries. I find debugging User Interfaces (UIs) in these environments can be challenging.
Using Web Inspector or Firebug on a desktop/laptop doesn’t trigger layout variations based on device orientation and/or device-width in a consistent manner, essentially keeping those styles hidden from me if that is the trigger I want for a media query. It may have been some buggy behavior in those cases or just really poor formatting for the cascade on my part, but it wasn’t predictable and that was my beef with it. Debugging in the simulator is no more fun than what I described above.
So, what are our options?
Right now, I only know of 2. I would really like to hear what other people are using, with a modicum of success in the comments for this post.
Firebug Lite Bookmarklet
It’s possible to use the Firebug Lite Bookmarklet if you are debugging a web page that displays the address and bookmarks bar at the top of the browser. If, however, you are dealing with an HTML app that “installs” to the device’s home screen, that option isn’t available.
Regardless, my experience with the Firebug Lite Bookmarklet on the iPad was frustrating. Trying to target the tiny little plus signs to drill down into the elements of the DOM tree in order to access what was nested inside was painful. My sausage fingers couldn’t accomplish that task with any grace. Zooming in allowed me to tap the correct thing, but the display would usually be out of whack until somehting triggered it to refresh.
Using the tiny panel that opens at the bottom of the screen was painful, especially having to use 2-finger scrolling to get at stuff that was further down the Firebug screen. It’s response is slow and laggy on an iPad first generation. I can’t speak for the iPad 2 (yet). It is possible to open the Firebug panel in a new window, but then you have to flip back and forth between the web page you are targetting and Firebug panel. Argh!
I gave up on that as a plausible means for debugging on any grand scale. Minor quick tweaking tests might be something I would use it for. But even that felt like it took too long for something so minor.
What, you’ve never heard of Weinre? It stands for Web Inspector Remote. It is pronounced “winery” if you fancy yourself too highbrow for the other pronunciation. Otherwise, the 12-year-old-boy in all of us may just call it “weiner”.
It seems that Weinre made its first appearance on github in December of 2010. It’s developed by Patrick Mueller (@pmuellr) of IBM.
Anyway, I had never heard of this tool either. I don’t know how I missed it! My coworker, Kurt, was about to embark on a lengthy process trying to build some way for us to debug UIs in the device. I protested, “Surely someone super smart has already solved this by now.” So, I Googled. It wasn’t at the top of the search results. I don’t even think it was on the first page of results – which must mean I was really commited to finding something so that we wouldn’t have to build it. Once I stumbled upon Weinre, it seemed really promising! So, I shared it with Kurt who had a little trouble getting it to work for him. We got busy with other work stuff, and this sat on the shelf for a few weeks.
I didn’t think all that much of it during those weeks. I just planned to figure out how to make it work once we had a break in the onslaught of daily tasks. The day finally came and I committed to figuring out this tool that seemed like it would solve a lot of my debugging woes.
It was much easier to implement than the documentation led me to believe. I think it is written in some kind of Sysadmin-ese. All I needed to do was download the Mac app, create a ~/.weinre/server.properties file with two options inside it:
- boundHost: -all-
- httpPort: (mine was 8080)
The only other thing I had to do to complete the setup was add this line to the file I would be debugging (Line wraps marked »):
<script src="http://[my Mac's IP address]:8080 »
In my case, I’m trying to debug an entire app. We have different views and partials/includes going, so I was able to put that line in just the main.erb file (a Ruby thing) and it would be included in all the screens across the app.
Once those preliminary steps were done, I was able to point my iPhone to my local development version of our application, while debugging it using a familiar Web Inspector-esque interface on my Macbook Air!
I certainly haven’t tested this particular tool extensively, but the preliminary results are very good! I’ll be diving into Patrick Mueller’s blogspot a bit more to find out what is available in this little gem. It is possible that I have found a tool that I can use on a grande scale for debugging the layouts and styles – and maybe even the interactions – of mobile apps and still manage to keep my sanity in check. The sanity part is clearly, debatable.
If you would like to watch the progress of the best kept secret for debugging mobile apps, check out Weinre on github.
Thank you, Mr. Mueller, for your efforts on debugging mobile!
In recent years, it seems that I have less and less time to do the things I would like to do as more and more of my time is taken up by the things that I must do. That’s why I often feel I don’t have the time to read everything about web technologies that one must read these days in order to keep up their skills. It seems that the trend in publishing, at least where web design is concerned, is to put the information “out there” in concise bits making the idea of reading a book less daunting than some of the voluminous tomes I have read in past years. At 135 pages (including the index), Adaptive Web Design is a quick read, packed with solid information.
In keeping with that theme, I’ll keep my review of the book brief, while still attempting to explain why I liked it so much. (more…)
Dear Mr. “I’m bad at blog titles“,
Not only are you bad at blog titles, you are bad at comprehending the progressive enhancement philosophy behind building websites/webapps.
Progressive enhancement doesn’t focus on catering to the least capable browser. It simply doesn’t exclude a less capable browser from providing access to all the content housed on the site. Progressive enhancement layers on various features in a responsible fashion in order to provide more capable browsers an “advanced” experience based on the technologies it supports.
The key principle of progressive enhancement is: Restrict no one from being able to get at the content they seek.
That doesn’t mean, make a crappy experience for all because of the lowest common denominator. Far from it.
A lot of posts in the first few days of January reflect on the year that passed and/or look toward the year ahead. That’s not my plan here. There’s nothing wrong with posts like that. I just don’t want to do one of those. I do, however, want to get back into writing. More specifically, engaging in conversations that may be more meaty than those we have on Twitter or Facebook. (more…)
I’m attending An Event Apart, a great conference for people who make websites. My plan is to take notes during the presentations mainly so that I remember all the great stuff I heard, but also to share with my friends who couldn’t attend.
I also plan to create just two posts – Day One and Day Two. So, if you are one of the folks following along, I’ll publish the post section at the end of each presentation. All of Day One’s presentations will be contained in Day One, while Day Two will be in a post dedicated to day two. Hopefully, that is plain and obvious.
On to the meat of the posts… (more…)
I also plan to create just two posts – Day One and Day Two. So, if you are one of the folks following along, I’ll publish the post section at the end of each presentation. All of Day One’s presentations will be contained in Day One. Hopefully, that is plain and obvious.
On to the meat of the posts… (more…)