Author Archives: ryanstewart

About ryanstewart

Ryan Stewart is a Developer Evangelist for Adobe focusing on web technologies. He lives in Seattle where he likes beer, anything to do with geolocation, and spending as much time in the outdoors with his family as possible.

Learn PhoneGap From Lynda.com

Posted on by
Reply

While things have been kind of insane as I start my new job I was lucky enough to be able to travel down to Carpenteria, CA and do a Lynda.com recording on Up and Running with PhoneGap. The title is part of their “Up and Running” Series which means it’s about a 2 hour course and is meant to provide a basic overview of some of the features behind PhoneGap. So it’s not an intense deep dive but hopefully for some of you looking into PhoneGap it will give you a good sense of how the APIs work and some of the general workflows.

Up and Running with PhoneGap

The video goes through setting up the SDKs, setting up a PhoneGap project, adding device-specific APIs, incorporating jQuery Mobile, and using PhoneGap Build to compile and test binaires. So if you’re a Lynda.com subscriber, check it out!

One quick note, there’s currently an issue with using jQuery Mobile 1.3 and the Handlebars templates I use in the course. I’m working on figuring out if that’s going to be fixed or if people will have to use jQuery Mobile 1.2.

I’m the Edge Code Product Manager

Posted on by
19

Update: In case there was any question, Adam is still PMing Brackets and he and I will be working together. So shenanigans will follow.

adobe_edge_code_mnemonic_rgb_128px_no_shadowThe past couple of months have been kind of a whirlwind of awesome, random things, and it all kind of came together this week when I accepted the role of product manager for Edge Code. So now I’m going to move from talking about products to actually building one and I’m really stoked.

For one, the Edge Tools family is off to a great start. I think they’re exactly the kinds of tools Adobe should be building more of and I’m excited to be in the trenches driving features and direction for one of them. The other great thing is that I get to work really closely with Adam Lehman and the Brackets team. I’ve actually been filling in for Adam on the Brackets team for the past 6 weeks while he’s been on sabbatical. It was a great experience and showed me that product management was challenging, time consuming, but ultimately deeply rewarding. So I signed up full time. Getting to build off of all the momentum that the Brackets team has created and then integrate with the other Edge Tools and Services as well as the Creative Cloud was too good to pass up. Plus, I get to work really closely with Adam and the rest of the Brackets team which is going to be great.

So onwards and upwards. This role will mean less, but more focused travel, so I’ll be hitting some of the bigger web conferences to speak about Edge Code and also talk to customers. We’ve also got some hackathons coming up for Brackets/Edge Code that I’m going to be helping out with. And of course I hope to see a bunch of you at MAX.

To end I want to give a big public shout out to Andrew Shorten who encouraged me to jump in (and will be my new boss) as well as Adam and the Brackets team. Getting a shot to try being a product manager was fantastic and it had a big impact on me.

Bookboard – A Model for the Future of the Web

Posted on by
6

One of the missions of PhoneGap has always been to bring about its own demise. The PhoneGap team wants the web to have all the functionality that we currently enjoy on devices so that there isn’t a need for PhoneGap to exist. It’s one of the reasons I love the project; I think that’s the perfect goal. I hope we get away from app stores and back to a world where the web rules all. There are obviously many things that have to happen before that becomes a reality but every once in a while I see a glimpse of what the web could be if that vision comes to pass. The latest iteration of that is Bookboard. (Sign up here)

Book Board Selection Screen

Bookboard is a web app that was written for the iPad. It makes heavy use of iOS specific features that allow websites to add themselves to the home screen for a full-screen experience and provide specific icons so that to the end user, it kind of feels like an app that just didn’t come from the app store. Even though it’s iOS-specific right now, the UI design is such that it would work across platforms. So many apps, even PhoneGap apps, follow the specific list->detail form that brings a lot of baggage with it. You have to work at making sure your list/detail view works the way it’s supposed to on iOS or Android (or other platforms). But Bookboard has a very design-heavy UI that lends itself to any platform. The books intuitively ask to be swiped from side to side as you are looking through them (with a nice parallax effect in the background) and when you go into the book itself you use the same swipe motions you would expect. It’s list-detail but brought to life in an interactive way.

Reading a Bookboard Book

Bookboard also makes use of hardware acceleration of CSS for many of its transitions. Everything on my iPad 2 is incredibly fluid and it’s difficult to tell that it’s *not* native. One of the things many app developers have to deal with is making their content feel native without it actually being native. The Bookboard approach seems ideal to me. They’re using a UI that hasn’t been replicated by every other app so they get a bit of leeway in terms of performance, but they don’t need it because they’re offloading to the device hardware via CSS. It works out very well.

Bookboard Menu Screen

Beyond the tech side Bookboard is simply a beautiful, well-designed app. It’s meant for children to read (and they can unlock achievements for reading more books) so it has to be intuitive, but it also looks great. Attention to detail like the parallax scrolling add a friendly touch and my daughter loved the app. She knows how to use an iPad and scrollable books, friendly gestures, and words that are magnified on touch all came naturally to her. If you’re a parent with a kid who enjoys reading (or you want them to enjoy it more) Bookboard is well worth a try.

This is how I want the mobile web to look and behave. Bookboard leverages the mobile-app centric parts of iOS to create an app-like experience while still retaining the unique, design-centric approach that has made the web so great. It’s this kind of custom UI and design influence that starts to make developers stop and think about whether they go native or web. A basic list-centric app isn’t that tough to do in native so more often than not, it probably makes sense just to go native. But the kind of custom UI and design that Bookboard uses lets you involve the designers much more deeply in the process. Since most designers (should) feel comfortable with CSS, they can jump in and contribute directly to the end result. If you can get performance like this using web technologies, I think it becomes a tougher sell to try and do native when web gets you more platforms, more reach, more designer input, and more deployment flexibility.

Hopefully in the next couple of years apps will have been replaced by experiences like Bookboard. It would make my home screen a much more interesting and beautiful place while giving developers ultimate flexibility. That’s a big win for the web. I encourage you to go sign up and see what I mean.

Web versus Native Economics and User Adoption

Posted on by
Reply

Vibhu Norby has a detailed post on why his startup is pivoting from mobile first to web first. And ultimately it comes down to economics. This has been one of the big problems with the web versus native. In general, it’s been easier for developers to make money with native apps. That ease comes at a price; you’re locked in to a specific platform, and you’re at the mercy of the keepers of that platform. But all-in-all compared to the cheap, throw-ads-everywhere model that has driven the web economy for so long, it was a breath of fresh air. People were willing to give up 30% for access to a new, untapped, and profitable market.

That market still exists, but it isn’t quite the gold rush it used to be. What more people like Vibhu are realizing however, is that you don’t have to choose between throwing a hail-mary on an app store and cheapening your user experience with ads. You can focus on building a great web experience and adding value, charging for that value, and then using mobile as an added touch point to your service. And it turns out that the early process of getting and retaining users is quite a bit less painful on the web.

You have an entirely different onboarding story on the web. You can test easily, cheaply, and fast enough to make a difference on the web. You can fix a critical bug that crashes your app on load 15 minutes after discovery (See Circa). You can show 10 different landing pages and decide in real-time which one is working the best for a particular user. You can also close a viral loop: A user can click an email and immediately be using your app with you. You can’t put parameters on a download link and people don’t download apps from their computer to their phone. Without the barrier of a download + opening the app to try your product, you can prove value to the user immediately upon their first impression, as is with Google. In addition, the experience of signing up for a service is superior in every way. Typing is easier. Sign-up with OAuth is faster. Tab to the next field. Provide marketing alongside sign-up as encouragement. Auto-fill information is a feature in every browser. The open eco-system of the web and 20 years of innovation has solved many of the most difficult parts of onboarding. With mobile, that kind of innovation is lagging significantly behind because we create apps at the leisure of two companies, neither of which have a great incentive to help free app makers succeed.

As a personal example, I have a long Facebook password with lots of random characters. Nothing annoys me more than trying to sign up for anything with Facebook on a mobile app because my password is hard to type, it’s not saved, and I can’t use the key combination I’m familiar with on the desktop. That’s not a good user experience.

There is so much that’s inherently good about the web, as Christian Heilmann eloquently points out, that it’s a shame to think of it last or as a throwaway just because mobile is the new hotness. Since the web has gotten very good at supporting rapid testing and process for getting users on board why not leverage that and then use mobile as just another way for customers to access your web-centric content/services?

Longer term I continue to hope that the good practices from the web will bubble up on mobile devices. From both a core API/feature standpoint and from a user experience standpoint. Once that happens it will become a much easier sell to content creators and developers to go all in with the web and build great web experiences on mobile instead of building native apps that tie back to the web.

Slides on New CSS Features

Posted on by
1

I spoke with Ray Camden at the Grand Rapids Web Developer/Designer Meetup this week on some of the new CSS features that Adobe has been working on. The event went well, Ray did an awesome job and hopefully I didn’t stumble through the CSS parts too much.

I’ve posted my presentation on GitHub for anyone who is interested. It’s high-level but shows off how to use some of the new features and shows them in action. To view the demos you’ll have to have Google Chrome Canary with the Experimental Webkit Features flag enabled. And the last part requires a prototype Webkit build from Adobe. If you have any feedback, let me know.

Using Ratchet with PhoneGap

Posted on by
13

When I saw the Ratchet project I was stoked. While the initial site talked about being able to prototype iPhone applications with HTML/JS/CSS it was pretty apparent that this could be something even bigger than that. And sure enough, on their README page it talks about long term goals:

We eventually want to extend Ratchet beyond the prototying for iPhone and create HTML/CSS/JS components for iPad and Android devices. Our dream is that Ratchet becomes the best way to create mobile experiences with web standard languages.

To me, that means this could be a great project for PhoneGap applications. So I threw it into a project and looked at getting it running. Unfortunately nothing happened. I could get some components to work but once I tried to move between pages it wouldn’t respond. I tracked it down to the push.js-esque functionality that they’re using. Specifically, it’s a single line of code that causes issues.

if (xhr.readyState == 4) xhr.status == 200 ? success(xhr, options) : failure(options.url);

The issue is that PhoneGap only seems to return a status of 0 when using XMLHttpRequest. I’m fairly sure this has something to do with the fact that it’s loading from the file system and not a server, but I’m not 100% sure. By making sure that Ratchet accounts for status of 0, page transitions work perfectly.

if (xhr.readyState == 4) xhr.status == 200 || (xhr.status == 0 && options.url.indexOf('file:///') != -1) ? success(xhr, options) : failure(options.url);

I’ve got the full project up on GitHub and you can bring it into PhoneGap Build and test it yourself. I’ve only tested it on iOS but it works pretty damn well. I’m definitely intrigued. I’ve also posted this to the Google Group to see if they can support this out of the box.

Update: Simon mentioned in the comments below that by tweaking the code to check for status 0 AND file system, it would be safer. So I modified the ratchet.js file in my project to take that into account. Thanks Simon.

Dealing with “fatal: https://github.com/adobe/Source-Code-Pro.git/info/refs not found:”

Posted on by
1

We recently changed the name of the Source Code Pro repository to follow the typical naming conventions of Github. Because of that you may get the following error when you try to update the code from git:

fatal: https://github.com/adobe/Source-Code-Pro.git/info/refs not found: did you run git update-server-info on the server?

If you get that, it means you need to update your local copy of the repository to point to the new URL. You can see all of your remote repositories by running:

git remote -v

You’ll probably see something like this:

origin	https://github.com/adobe/Source-Code-Pro.git (fetch)
origin	https://github.com/adobe/Source-Code-Pro.git (push)

Then you can run another git remote command to update the URLs to the new lower-case versions:

git remote set-url origin https://github.com/adobe/source-code-pro.git

Run git remote -v again to make sure your origin is set to the new lower-case URL and you’re all set.

Forks

If you’ve forked the repo and added an “upstream” link to the original source so you can track it, instead of origin you’ll want to set-url on the repository pointing to the Adobe source. Usually that’s called upstream but you may have named it something else when you set it up.

Speaking at Seattle Google Developer Group’s Devfest

Posted on by
Reply

There has been a lot going on and I’ll cover it over the next few weeks. But this weekend, on Saturday at 11:00, I’m going to be speaking on PhoneGap for the Seattle Google Developer Group’s Devfest. The whole conference looks awesome so if you’re in the area, sign up and learn a ton about creating apps across device form factors.

The Mobile Web is Always the Right Answer

Posted on by
15

It’s been interesting to continue to watch the fallout of Facebook’s native announcement because so many smart people are discussing the web versus native dynamic. What I find both fascinating and odd (yet unsurprising) is that “HTML5″ continues to have vague and very subjective connotations. In the context of this debate, HTML5 seems to really mean hybrid applications that are built with technologies like Cordova/PhoneGap. And for proponents of native that’s a great way to frame the debate because when compared on equal ground, native will win most of the time. That’s because native apps were meant to be apps whereas PhoneGap/Cordova apps are really web content that’s built to behave in an application world. The suit will never fit quite as well as it does on Mr. Native.

But in some ways, that’s not the point. The real debate, and the most important one is the role of the web in the future of mobile devices. Currently there are number of techniques to bring the web to mobile devices. There’s responsive design, there’s the m-dot, there’s PhoneGap/Cordova, etc. They all have specific plusses and minuses depending on what you’re trying to accomplish. But they’re also all very rooted in the ethos of the web.

When people talk about HTML5 versus native it’s often going to be in the app context. And then the narrative can become “HTML5 isn’t ready”. That’s bullshit. HTML as a technology is more than ready to help you create apps and content for mobile devices. You may not get access to every device API and it may not fit into an app store, but the corollary is that you don’t need an app store. You can create whatever content you want and give it to the world. You have to make sure the experience is good on devices, but you don’t have to pass anyone’s arbitrary test to play the game, you don’t have to lock yourself into a specific platform. You just create your experience and let the world decide if it’s worth visiting. And users still do a ton of interacting with the web on their phone through a browser.

Facebook Mobile Usage Numbers

Facebook’s mobile usage numbers by platform

The image above, from PhoneGap Day EU during a talk by Facebook’s Simon Cross, perfectly illustrates that. There’s definitely a legitimate argument to be made that part of the reason the web usage is so high is because the hybrid Facebook apps were horrible to use. But look at the graph again. Mobile web usage is levels of magnitude above the native apps. That’s not just from a bad experience. That’s because people spend a lot of time in their browser on smartphones.

We’re in a fantastic time for the mobile web because there are so many options for creating mobile web content. But no matter how you want to show your content, it’s never a good idea to ignore the mobile web. Every great app I can think of has some tie to the web. Foursquare, Yelp, Untappd, and Twitter. The native app experience is a critical part- and it may even provide the best experience currently- but the web is even more vital to the long term survival of those companies. Never, ever discount HTML and the web. You’ll regret it. You can ask Path in a year how it feels.

Don’t Settle for a Mediocre HTML5 App Experience

Posted on by
17

Since Facebook announced their decision to ditch their HTML-centric app experience for a native one, I’ve been doing a lot of thinking about what that means for the HTML5 versus native debate. Unfortunately we’re at a point in the circle of tech where it’s easier to build a great native experience than it is to build a great HTML experience. I’d argue it’s not impossible to build a great HTML experience on mobile devices, just more difficult (I think Untappd is a great example, photo bugs not withstanding). The problem is that runs directly counter to why most people choose to go the HTML route and that causes a host of issues.

Today, when someone decides to build a mobile app from HTML, it’s primarily a developer-focused decision and not a user-focused decision. What I mean by that is that often times HTML makes it easier/faster/cheaper for someone to deploy a mobile app. Maybe they have a bunch of web developers and want to quickly crank out an app. Maybe they want to target multiple devices and they see HTML as a way to reuse code. Those aren’t bad reasons to chose HTML5 necessarily, but they do drastically change the goals of a project from “make this as awesome as possible” to “make this as good as we can with our constraints”.

So it’s no wonder that a lot of the HTML mobile app experiences are subpar. They started with the very premise of wanting to do it cheaper/faster/easier. That’s not a path to software greatness. Facebook again provides an example here. They had a ton of HTML content they wanted to reuse and an HTML-centric app was a fast, easy way to repurpose that content for mobile apps. Plus they could deploy it to lots of different kinds of devices with minimal code changes. They didn’t start from a place of wanting to make a great mobile experience, and the results spoke for themselves. When pressure finally got to a breaking point and they had to create a great mobile experience, they went with the clearest path to that route – native. This tweet by Josh Clark implies as much. It wasn’t that the HTML app was fundamentally unfixable, it was that (I assume) they looked at what it would take to make it as good as the native app and decided it wasn’t worth the effort.

I don’t blame people for making that judgement call. The PR boost that people used to get from throwing HTML5 into their marketing has started to subside and at the end of the day your users aren’t going to forgive a crappy mobile experience because you got 5 in a row on buzzword bingo.

HTML developers are in a rough spot right now because once you take out the faster/easier/cheaper argument, it’s tough to provide reasons why HTML is better than native apps. I see three main reasons. One, the web is a fantastic medium for designers and allows very unique experiences. Two, the ecosystem around web technologies has never been stronger and the number of cool frameworks, tools, and libraries that are available to web developers could have a significant impact on the kind of app you can build. Three, it never pays to bet against the web.

The first two I’ll cover in later posts and the third is the most subjective anyway so I want to talk briefly about that. For most apps, the future isn’t going to matter, so this isn’t a “future proof your code” argument. It speaks deeper than that. Do you want to be the kind of company who makes the future, or do you want to be the kind of company who follows along? HTML is the future. Just like native fell out of favor on the desktop, native is going to fall out of favor on mobile devices. The APIs are getting better for device access. Core graphical capabilities are being added that will make for nicer components, better experiences, and faster UIs. And the web is bigger than one company. The web is the great equalizer in tech. That leads to its own sets of drama about how we add features, but at the end of the day, no one will own or control the web. I see the web as a glacier. It tends to move very slowly, which can be a drawback. But when it moves, it brings everything with it and it carves a deep, permanent path that completely changes the landscape. That’s a tough thing to try and stop or stand in front of.

When you see an HTML mobile app that’s not as fast or snappy as it should be, think about what problem they were trying to solve. If the answer isn’t “build the best app possible” then don’t take that as a good example of what HTML is capable of. And if you’re building an HTML app put the same amount of effort, thought, and design into it as you would a native app. With the breadth of design possibilities, the HTML/JS/CSS ecosystem, and some forward-looking vision, you can build something that helps turn the conversation back to why the web is such an awesome medium for applications.