Shallow Thoughts

Articles

• About
• Portfolio
• Resume

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.

Weinre

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:

1. boundHost: -all-
2. 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="/img/spacer.gif"> /target/target-script-min.js#anonymous"></script>

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!

One cool thing is when I hover over the element in the Weinre Elements tab on my laptop, I can see it in the display on the iPhone just as I am used to from using Web Inspector or Firebug in the past. I could make changes to the CSS in the inspector on my laptop and they would appear as changes on the iPhone. It even has a working Javascript console!

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.

Tim Van Damme wrote a very helpful tip for adding CSS3 rounded corners on images. To get the rounded corner effect, Tim placed an additional element around the img tag — in this case a p tag. To that p tag, he applied an inline style to set the background-image to be the same as the image being displayed on the page. Then he wrote some CSS3 magic using border-radius to round the corners. Not every image you come across will need this solution, but if you read what he wrote first, you might see why this strategy would come in handy.

The issue that arises for me comes when handing the site off to a client who will be adding images later. Depending on their skill level, they may or may not be savvy enough to add markup around an image to make this effect work. So, I’ve opted to add that element automagically using jQuery. All the caveats that go along with other javascript solutions apply here.

In my scenario, there is already a div with class=”figure” containing the image that is to have its corners rounded along with some additional text. In fact there are multiple div‘s with class=”figure” on the page. So, this snippet of jQuery finds the images inside each of those divs and applies the additional markup to them:

$(document).ready(function() {

// find images inside the divs with the class of
// "figure" - and for each of them do some stuff 

  $('.figure img').each(function() {

// store the src attribute for the img because we
// need it in the next bit

  var imgSrc = $(this).attr('src');

// wrap the image in a p tag and use the src
// attribute we stored earlier in the inline style
// on the p tag

  $(this).wrap('<p style=""/>');
  });
});

That’s all there is to it. Now each of the images will have the p tag with the inline style added to them, in order to make use of Tim’s delightful solution.

Silly things one can do with Baskerville’s Ampersand:

Pandoodle

Part Panda. Part Poodle. Pandoodle.

Simple Snail

Nothing fancy. Just a snail.

Red Hot Chair

Fancy Chair. Simply done.

Swirly Flower

5 ampersands rotated around. Shrug.

Walrus by request

Highly coveted walrus. 2 ampersands.

Those of us who follow the likes of Jeffrey Zeldman, Andy Clarke, Dan Cederholm, Ethan Marcotte, and a host of other notable web professionals have heard the battle cry that design should support the content, not the other way around. I’m not going to reiterate all the reasons why this is a good practice. You can get their thoughts on the matter via their blogs, books and presentations at conferences. I encourage you to do so because I agree with them. Content should be honed first, so that an appropriate design can deliver it in a pleasing manner to the intended audience.

The question I am posing today is how to best put this philosophy into practice when a CMS and other restrictions come into play. Lets face it, not every site can have each article “art directed” a la Jason Santa Maria‘s site. Not every company has the resources available to do such a thing. So, in the harsh, cruel world where low budgets, unenlightened project managers, unrelenting time lines, and understaffed companies govern the website’s resulting look and feel, what do we do to ensure that content is delivered in the best possible light?

I have a specific scenario I’d like to examine, in hopes of hearing some ideas on supporting content while using a CMS in the conditions mentioned above. (more…)

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…)

A simple game: Go to supplements for pets
the address bar in your favorite browser, and type one letter. Start with “a”, end with “z”.

A - aremysitesup.com/
B - bradcolbow.com/
C - www.clevelandwebstandards.org/
D - www.dailypuppy.com/
E - expressionengine.com/
F - forabeautifulweb.com/
G - www.google.com/
H - www.hulu.com/
I - www.imdb.com/
J - jquery.com/
K - kuler.adobe.com/
L - localhost:8888/
M - microformats.org/
N - www.newint.org/
O - orderedlist.com/
P - photobucket.com/
Q - (nothing)
R - www.rockportretirement.com/
S - shallowthoughts.org/
T - twitter.com/
U - upcoming.yahoo.com/
V - www.virtualrabbit.com/
W - www.watchtheguild.com/
X - (nothing)
Y - www.youtube.com/
Z - www.zeldman.com/

A few of the above reflect some recent work I did on a website project and services they wanted to include.

Other lists to look at:
Tim Van Damme (the guy to blame for this game)
Andy Clarke
Brad Dielman
Elliot Jay Stocks

If you are using Twitter as a means to communicate with other people, super. You’re not the only one. There are tons and tons of us out here using Twitter and as a means to make Twitter a useful service, I only see the tweets from those I follow. At least, that’s the theory.
(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…)