Author: tpryan

jQuery Mobile and Semantics

I’ve been fooling around with jQuery Mobile, and I really like what it’s capable of accomplishing. However I’ve had one nagging gripe with it. The amount of <div>s you end up creating. Most of the sample code looks like this:

 

http://snipplr.com/js/embed.js
http://snipplr.com/json/61645

That’s a crap ton of <div>s for just one view. Not that there’s anything wrong with
<div>s. It’s just you get this many on the page and things start being hard to keep track of. “Is this the <div> that closes the header, the footer, the content, or the page?”

 

HTML5 added all of the cool new semantic elements like <header>, <footer>, and <article>, which help you describe your content better. It would be cool if you could use them with jQuery mobile. The data-role attribute still makes sense because as elements there can be more than one of them on a page–for example, a page header and an article header.

This is especially weird when you consider that “data-role” itself is an HTML5 construct. So why do we have to use <div>s everywhere? You don’t. Something that wasn’t entirely obvious to me before I tested it out is that you can totally use the new HTML semantic elements in your code, as it would appear jQuery mobile only cares about the data-role attribute when it comes to picking out your application elements. In retrospect it makes sense. Doing nothing but
<div>s in example code simplifies things, but it can be done much more semantically if you want.

 

http://snipplr.com/js/embed.js
http://snipplr.com/json/61647

Now, to be clear, I’m not saying I recommend you mark up your code this way in all cases. I’d say a page could be considered a <section>
as it is a collection of related elements, but
<div> is pretty much just as correct. With headers and footers, it makes a lot of sense to use them. The whole <header data-role=”header”> might seem a bit redundant to some, but it beats a crap ton of <div>s in my book. Finally, only really makes sense if the content is standalone.

 

So I don’t think everyone should run out and do this. And I haven’t tested it out more rigorously than just a rudimentary proof of concept. But I’m going to do this, because I really like it.

One Click PhoneGap Build to Android Device Script

I’ve been fooling around with PhoneGap Build, and I really love it. I love that I don’t need to fire up Eclipse or XCode to start fooling around with an app. All I need is a text editor and a browser. What I especially love is the ability to integrate a github repository to the whole process. It makes following proper development practice, while living in the cloud, very easy.

But I’ve been spoiled for the last year or so. Being able to immediately preview on a connected device has ruined me for the command line, multi-step, manual crap. So at least on Android I’ve fixed it for myself by building a nice shell script that takes advantage of PhoneGap Build’s Web APIs to create a one-step build.

What’s involved:

  • Commit all uncommitted files to git repository
  • Push git repository to github
  • Tell PhoneGap Build to poll github for changes
  • Poll PhoneGap Build until Android apps have been rebuilt
  • Download App
  • Use ADB to install onto attached device.

So I wrote a little shell script to do it all for me. I hope it helps someone else who is struggling with the same workflow issue. The script is below.

http://snipplr.com/js/embed.js
http://snipplr.com/json/61101

The Fetishism of Douchebaggery

In the wake of Steve Job’s passing there have been a number of takes on his character and impact. One of the common themes that have permeated a lot of reactions in the blogosphere and twitter is Job’s tendency to be a douche. Most people have been negative on this, but a recent article, The Jerk on TechCrunch by MG Siegler has gone the other way, stating:

the tech world could probably use more jerks.

I couldn’t disagree with this statement more, although I agree of much of what Siegler is saying in article. How is that? That sentence is the sound bite distillation of a bigger point: we need more and better criticism in the tech world. That is totally true and not contested; however, I contend you don’t have to be a douche about it.

Why not? Siegler argues that Job’s and in his case Arrington’s abrasiveness had a positive impact. Mostly because in both of these cases, they deal with someone in power being douchy to someone with less power. People have to listen to their superiors, even if they don’t like it.

Most of us in the business of driving technical change are advocating to equals or superiors. When people aren’t compelled to listen to your douchiness, they don’t. Poor delivery in these cases will almost completely ensure that no one will listen to you, no matter how right you are.

Additionally, it presumes that somehow Steve Jobs could be Steve Jobs, give respectful criticism, and people would have not listened. Granted, perhaps being Steven Jobs had to include that abrasiveness and so is unavoidable. But I think once he made it, once he was the great and almighty Steve Jobs, he didn’t need to use it as a tool anymore. Yet reports state he still did. I’d believe that his abrasiveness was a slight obstacle to his success that in his case was outmatched by the rest of his considerable positives. Steve Jobs had a huge impact on the world, far and beyond what most people accomplish. In this sense he was a “Great Man” in the classic definition of it. However that does not mean that everything about him was great, or an advantage. Grownups can admire people and yet still acknowledge flaws in them.

But in any case, I’m not informed enough to know if douchiness worked for or against Steve Jobs with any authority. However I’m firmly convinced that it won’t work for the rest of us.

 

Semantic HTML has Other Benefits

Just got done reading Our Pointless Pursuit Of Semantic Value at Smashing Magazine today. It’s a good read, and clearly spells out a true point: There is not a lot of value in wrestling over how semantic your code is for semantic’s sake. I totally agree with this. While SEO and accessibility are often cited as reasons to pursue semantics, quite frankly, there is a lot of thought that semantics don’t help as much as people think (examples of which the author notes.)
Does that mean that semantics are worthless, and you should just use a div and a span for everything? No, and I don’t think that’s what the author is saying.
Semantics means different things to different people, but I’ve always looked at it as the process by which I identify things in the markup. This identification is important because it’s what I use to go back and manipulate things through CSS and JavaScript. In that way the process of making your HTML semantic is a lot like naming variables in more traditional programming.
So I see the new set of semantic options in HTML 5 as more choice, and I welcome it. Why? Because it makes it possible to turn this:

https://gist.github.com/1358362.js?file=gistfile1.html

into this:

https://gist.github.com/1358370.js?file=gistfile1.html

It’s not a huge differece, and doesn’t change anything about the presentation, but does make it easier to read. So it allows me to write more easily understood and maintainable markup. Now that doesn’t mean I arbitrarily use new tags. I do consider the meaning behind the tags when I use them. But not so much so that I allow myself to get paralyzed by it. Do I care that 
address doesn’t technically mean postal address? Not in the least. Do I care that dl might not be blessed to be used exactly the way I am using it. Nope.

It comes down to this, using Semantic HTML in the hopes of communicating to browsers and accessibility tools might have some diminishing returns. However using Semantic HTML to communicate to other developers can still yield a lot of value.

Finicky, now for iPhone

I released a version of Finicky for iPhone earlier this week. It’s up and running in the app store.

Design Differences
You’ll notice that it looks somewhat difference from the Android version. This is by choice. In trying to get the iOS version working, I noticed significant issues with the UI we had designed and the iOS version. However I was still able to capture the feeling I wanted through color and font, without having to compromise too much on the design.

Feature Differences
I was able to support pretty much all of the features on both devices with the exception of mapping. I had issues getting the maps to work in production build. Worked fine in both the desktop debugging version of AIR and the fast compile version of the iOS app. It only failed on the full compile version of the iOS version. I anticipate having them working in an upcoming version.

Coding Differences
My original path was to have 2 separate code bases. I know, I know, this is all about not having to do it twice, but I was weak. The major reason behind this was that the iOS version had to run leaner, because, well, you know, performance is king. There was a good amount of Android specific UI and features that I just set to visible = false. That did terrible things for speed. So I stripped out all Android specific code, removed anything from the UI that I wasn’t showing on iOS, and generally improved performance.
However, after awhile I found two code bases presented a lot of problems. See, I’m not the best coder. I know, shocking. But I had bugs in my code. And I found a lot as I was going through and tweaking for iOS. But I had to manually copy them back to the Android project, as my git-fu is not so great.
I went back to one code base, but instead of ripping out Android specific UI and features, I loaded them conditionally. This gave me comparable performance, but allowed me to run both apps from the same code base.

2 Targets 1 Code base
If I had to do it again, what would I do different? First, off, due to some advice, I made a couple of good calls early. Kevin Hoyt pointed out, and Renaun Erikson echoed: design for iPhone 4 first, in terms of design assets. Everything else is a step down in terms of resolution. However, I developed for Android first. I’m not sure if this is the right move. I think it’s easier to add things, then it is too take them away. My process had me taking a whole bunch of things away. If I had it to do over I might develop for IOS first, then selectively add features for Android, BUT release for Android first. Maybe… I dunno. The thing I love about releasing on Android first is that I get stupid bugs out of the way on a platform that allows me to iterate through releases as fast as I can fix bugs. This isn’t necessarily a shot at iOS or Amazon or Nook or BlackBerry. I think their approval system does make you think harder about whether or not you have bugs before you submit. But, that being said my problem is not that I do not think, but rather that I often don’t think the right way. Being able to quickly react to real issues, is better then having me ruminate on what I think might be happening.

So there you have it. One app two platforms. Will be getting it onto Amazon and Nook next.

Motorola at Adobe MAX

If you’ve done any Android targeted development, you’ve had the experience of getting your app out only to realize that your app looks terrible on a device you didn’t consider testing. Maybe nobody you know has it. Maybe you thought it would work alright because it works on a similar device. But it’s embarrassing, gets you bad reviews early out the gate, and frankly is a hard problem to combat. You can’t own every device.

Which is why I’m excited that Motorola Mobility is up to something really cool with their sponsor booth at MAX this year. Instead of merely showing off their latest and greatest device, they are setting up a test lab in their space. The test lab will do 3 things:

  • Let you test your device on Motorola devices
  • Help you get your app on the Android Market (They’ll cover the developer license)
  • Potentially aid you in marketing via Motorola Mobility

All in all this is a great opportunity to get some help from an actual device manufacturer with tons of experience in bringing mobile apps to market. It’s tough for a lot of us who are lone mobile developers to get this type of feedback. All you have to do is stumble* into the Motorola Booth at MAX to get it.

This past year I’ve had the great pleasure of traveling with some of folks at Motorola Mobility during their tour for the Motorola XOOM. They’re a great bunch of people to work with, and they have the same passion for their community that we at Adobe do for ours. They’re a great fit here.

This is an awesome opportunity; I recommend that if you’re at MAX you take them up on it.

To find out more, check out the MAX Blog: MotorolaMobility@MAX.

* You can also walk, jog, stride, hop, roll, shuffle, or dance into the Motorola Mobility Booth for the same treatment. Swaggerers need not apply.

Introduction to ColdFusion – Winners

I finally have winners for my ColdFusion Developer Week software giveaway. (I had to wait for them to both respond, letting me use their names and whatnot.)

They are:
Wade Stockton, who referred Erik Stant.

I asked Wade why he made the referral. He said:

I work as a contractor for the Air Force. Erik is one of the troops I work with. He has done some Java web work in the past and was interested in CF but needed a kick start to get going. Part of it was selfish on my part, I need help! I have had a couple of really big wins for CF in the shop lately and the requests are piling up.

Jump in there Erik; ease his burden.

Both will receive copies of Master Collection.

That’s right, even though I said I wasn’t going to offer suites I did. The reason I did was the wonderful response I got. I had a great number of referrals to the session, and I thank you. We had a total of 360 signups with over 200 attendees for an Introduction to ColdFusion session.

Thanks to everyone who spread the word.