I was having a chat with a friend about app marketing, and the app store. The reason why they are starting off with a native iPhone app is due to the massive call to action presented with the “Available on the app store” image.
Search for “ArtSpotter”
This image provides the user with a MASSIVE call to action. “Oh right, that is where I can find it”
That got me thinking. Personally the process of finding a website online is far easier, especially if I know the domain name. So that got me thinking, for purely marketing of web apps do we need to start using something like this:
Visit artspotter.com
Now although the fact that it says artspotter.com is pretty easy to me perhaps users actually need to search for something.
Search for “ArtSpotter”
Obviously I would rather the Available online would work better but I have a worrying feeling that “Google it” might work better.
Maybe this is the reason why HTML5 has a logo?
Mozilla are soon to be releasing their own app store. For the general mainstream, the ones who type into google “facebook”. These are the people we need to help get our warez into the hands of to go mainstream.
I think the web community needs a cause to get behind for the good of the web. Who’s with me?
My slides from Mr Mobble’s Magical Emporium, October 2011
My slides from Front Row Conference, October 2011
Take yourself back to 2007. The first iPhone was released… The media, love to claim that this device changed everything. One thing everyone seems to forget is that at first, we, as developers, could not make applications for the iPhone. There was no app store. There were no apps.
What was Apple doing? They were pushing for the web. They said, “Just make a web app”. They had their ‘add to home screen’ functionality (which is yet to be duplicated by other manufacturers, but it REALLY needs to be).
The problem with this solution was that developers wanted access to cool stuff. We wanted to play with the camera, the location services, the address book etc.
Now imagine this scenario. Apple improve mobile safari at this point to include access to all the native functionality and features. This would be what Mozilla are trying to do with their WebAPIs. Or perhaps what W3C are trying to do with the web applications API. They also add hardware acceleration and key performance improvements at this point. They make web apps, look and behave like native apps.
Now what would other manufacturers have on their devices? A decent brower that enabled developers to have access to the native functionality of the device. Now remeber, the beauty of the web is that any device anywhere can access it. There are only two requirements, a browser & an internet connection.
But what did Apple do? They released a native SDK in their very own language of choice Objective-C. Developers then started making native iOS apps. Only iOS devices have access to these tools and services. Native apps aren’t new, in fact they are old. So what was the big deal? The App Store, that is what changed everything.
Don’t get me wrong, obviously there are still the type of tools, that can’t work well using high level languages. Native apps will always be with us for heavy duty software. But for angry birds? For the type of app your mum has downloaded and installed. Do these really need to be native? No.
What we need now is device manufacturers to develop decent browsers with native funcionality APIs and the “Add to home screen” functionality.
atomoco:
GPU memory management with hardware accelerated CSS transitions.
See that? That’s the difference that GPU hardware acceleration of CSS transitions can make on an iOS device. If you don’t know what CSS transitions are, you might want to stop reading now.
For those that are left, I won’t bore you with how CSS transitions can provide basic animations, or how they can be GPU hardware accelerated on iOS devices, which can make an incredibly low-powered platform like an iPad offer smoother animation than big desktops running javascript.
Instead I’ll run through how Bardot currently does the “next page” trick, and how I’m trying to improve it.
As a caveat, I’m just imparting what I’ve learnt through trial, error and Google - I wouldn’t count myself as an expert on this.
Bardot is built in “pages” and “spreads”. Pages are… er, pretty self explanatory, and spreads are the equivalent of opening a magazine spread (ie two or more pages facing each other). Bardot actually has three piles of spreads *, at any one time you see only one spread on-screen - in the “viewport”. Either side of the viewport are two other piles, and when you hit the “next page” button, the piles all shuffle along one direction or the other.
The mechanism for doing this on most modern browsers is simplicity itself. Spreads in each pile have a particular class (“.read”, “.active”, “.unread”) and to move them around means changing their class via javascript, CSS transitions and transforms do the rest for you. As an aside, that makes quick changes to the animation a doddle (Make it quicker? Tweak the CSS style. Add a 3D flip out movement? Tweak the CSS style).
That all looks fine on desktop browsers, but iOS devices need a bit more help. They’ve got pretty limited processing power, and extremely limited memory, which often ends up with low frame-rates, sudden disappearances, or giving the “tiling” effect you see in the video above. This is especially true when you’re creating something off-screen, then moving it into view (like we are here), because mobile devices are optimised to only deal with on-screen pixels to keep them lean and mean.
To get around that, we can hand off the “compositing” of certain elements to the 3D GPU chip in the iPad or iPhone, which is way more adept at flinging tiles around a screen. You can move an element to the GPU by adding a 3D CSS style to an object (some use “-webkit-transform:translateZ(0)”, others use “-webkit-transform:scale3d(1)”)
In the case of Bardot, I created a style class called “.zippy” with a transform of “translateZ(0)”. When a page-forward event occurs, the top of the “.unread” pile is changed to a class of “.active.zippy”, and the retreating spread is given a class of “.read.zippy”. So “.read” and “.active” are the classes that determine where the spreads move to, and “.zippy” is the class that adds a sprinkling of acceleration.
The question begs: “So why don’t we hand everything off to the GPU with 3D CSS?”. Well, the GPU is also really limited in the amount of memory it can handle, and the more you stuff into it, the more it stutters and you’re back to where you started. In Bardot, one of those spreads could be thousands of pixels in size, it doesn’t take many of those to really bung up a GPU.
The trick is memory management. In Bardot, only the “.zippy” spreads are hardware accelerated, and once a spread is moved off-page, the “.zippy” class is removed to reduce the load on the GPU.
The result is buttery smooth animations in both directions. Simples.
* Note: I’ve tried building systems with a long continuous “conveyor belt” of pages in the past, and although the theory behind that is cleaner (moving a huge track of pages past the viewport), I find working in three piles is easier to manage, especially when you get into dealing with layouts that are many spreads long. A track would becomes tens thousands of pixels wide and you have to deal with big margin offset numbers. Not pretty.
(Source: ukd1.co.uk)
Currently (at time of writing) there are 4 main desktop platforms (Windows, Mac, Linux, Chrome OS) and 6 main mobile platforms (iOS, Android, Blackberry, Windows Phone 7, Symbian, WebOS). In the future there is going to be even more platforms. Smart TVs will become mainstream, even the long awaited smart fridges.
Each of these platforms support applications of one type or another.
The current feeling, by many, certainly not all, and not sure if even most. Is that there has recently been a flocking to the native applications.
Why is this?
“You get a better experience with native applications”
I think I might be alone in this, but I hate this kind of argument. A ‘better’ experience depends on what you are actually wanting to experience. If you want something that you can access from any device anywhere in the world. Then the web provides an infinitely better experience.
You can put in extra functionality in a native application
Camera, Address Book, App purchases etc. These are either not possible via the browser or just not ‘easy’ to implement.
Now let’s take it back a few years ago. We had various desktop platforms. Mobile platforms weren’t really mainstream. The web was a wonderful place. Us makers, developers, software craftsman could make something that everyone with an internet browser could use. That was all you needed. That one application, the browser. It didn’t matter what desktop platform you were using. The web was our new platform.
So why have we gone back to the past?
My answer is simple. Mobile browser vendors.
They have only recently implemented hardware acceleration into the browsers. That isn’t necessarily their fault. Let’s remember that the standards have only recently been formalised.
But more importantly, they don’t currently implement any of the useful native features.
Many of you will have heard of PhoneGap. PhoneGap is basically a browser wrapper adding these extra bits of native functionality into applications built using web technologies.
PhoneGap in my opinion is an excellent interim solution, but it won’t be long until browser vendors start implementing native functionality. The problem we have is again the standards issue.
W3C have a draft proposal for their Device APIs
Mozilla are creating their own implementation, WebAPIs. Which is set to be completed within the next 6 months.
As long as you have a good browser, your device won’t become a brick,
Paul Rouget
I don’t write for devices. I write for people.
Jeremy Keith
I guess what I am trying to say, is let’s not have the same discussions we were having back when the web became the platform the first time round.
By now, I am sure you are aware that you can use web technologies (HTML, CSS, JS) to build ‘native’ mobile applications. Well you can also use these technologies on other platforms too.
I have compiled a list of resources for other platforms, (this is mainly for my own use, but I thought I would share it also :))
Mobile
Titanium Mobile (iOS & Android)
From the guys at Appcelerator. This compiles your application into native code.
PhoneGap (6 different platforms incl. iOS, Android, Blackberry, WP7)
This open source bit of kit is now also bundled in with Adobe Dreamweaver, for all the developers who use Dreamweaver as their IDE. Unlike Titanium, PhoneGap doesn’t compile your code. It simply sticks it inside a native app container and uses the onboard browser for rendering. Uses the native browser rendering engine.
NimbleKit (iOS)
I am yet to use this framework, but my first impression is that it pretty much does the same as PhoneGap, but it only supports iOS. Uses the native browser rendering engine.
Desktop
Titanium Desktop (Windows, Mac, Linux)
Another product from Appcelerator. Again, this compiles your app into native code.
Adobe Air (Windows, Mac, Linux)
The old man of the group. Adobe Air has been around for a while now. My issue with it, is it adds an extra layer of complexity for the end user, they require adobe air). Uses the the WebKit rendering engine.
Intel AppUp Encapsulator (Windows & MeeGo(?))
Made by Intel. This is a relatively new kid on the block. I am yet to use this, but from my understanding this works in a similar way to PhoneGap for mobile, in the way that it just renders the app in a browser frame. Uses WebKit.
WebView (Mac OSX)
This isn’t a framework, this is simply some sample code for a WebView, to create a Mac app in the same way as using Intel’s Encapsulator. Obviously uses WebKit.
Windows 8 has native support!
I don’t have any information on this as yet. Only their announcements
Smart TVs
The new ‘modern’ ‘hi-tech’ ‘smart’ TVs by various manufacturers, Samsung, LG, Sony all feature apps
Samsung
These apps are built as ‘native’ using HTML etc :)
LG
Interestingly, these apps are built using flash. If you don’t know any actionscript but you know JavaScript, you should find it reasonably straight forward.
Sony
The new Sony TVs are powered by Google TV. Google TV in turn is powered by Android. Therefore to create an app for the Sony TV’s you need to create an Android app.
Other Gadgets
Nook
The Nook uses Android as it’s foundation.
Nintendo Wii
To create games / apps for the Nintendo Wii you can create them using Flash. However, from my understanding the SDK is a couple of thousand dollars.
Kindle
Well Amazon launched a beta program for the developer kit back in January 2010. I smell vaporware, but I thought I would list it just in case. By the look of things you can’t use web technologies (yet) but I thought I would include it anyway. It supposedly would use Java, so someone *should* be able to modify PhoneGap to work on the Kindle as it does have a browser.
Ford SYNC
I thought I would throw this in here as they are supposedly launching an SDK at some point in the future for their in car app store.
Next stop, fridges ;)
Samsung have relased a range of smart fridges, however I can’t fund any infomation on SDK and currently have no idea how the apps are built.
What other platforms would you like to develop for? PlayStation & XBox games can’t be developed using any web technologies (yet).
As you can see from above. We are almost there with a unified language to develop truly cross platform development. However we are extremely close!
I might be a little late to the game. But I had to wait to publish this blog post.
Almost a month ago now, Color, was released to the world. Along with the tech press being set on fire about it receiving $41M investment before it was even launched. For those of you living under a rock, the color app is a photo sharing app, but it only shows you photos within 100m of where you are positioned. Now there are a few other things it does which is quite clever ‘scary’. Each time you take a photo, it records your geolocation (obviously), data from the iPhone’s light sensor, a short sound recording. It uses this data to try and pair you up with someone similar, apparently.
The actual app itself, is not worth much at all. To prove this point, I myself have just launched a new location based photo sharing app (hence the delay for the post). My app is called ‘Local Eyes’. How is Local Eyes different to Color? Apparent to the user, there is little difference. I have spent a total of 12 hours on the app. Is 12 hours of my time worth $41M? I wish! (If you would like to give me $41M for 12 hours of my time, please let me know!)
The investment is not in the app, it is in the company behind it “Color Labs”. There is a lot going on in the background, not just with the ‘Color’ app, but the company itself. They are a data mining company, data is worth a heck of a lot of money.
Unfortunately, Color has had a bit of a rollercoaster ride since launch. At launch it got all the press it could have ever hoped for. This meant that thousands and thousands of people will have downloaded the app. (I don’t know the actual number). However, when people hear that an app has received that number of investment. They expect the world. Unfortunately color was a confusing app. It therefore received a lot of negative reviews. Getting back from negative reviews is very tough.
The reason why people don’t get Color, is because it only works when there are already users around you. Most users wont be the first people to share images. Not unless they know there are people there. I believe color should have launched at SXSW. That would have been a perfect launchpad for it. People would get the concept straight away. It is great for small events.
Local Eyes on the other hand, limits photos to 1 mile, and so it is more about what is going on around you, and not just the same thing you are seeing. I am about leave my full time job to concentrate more on (amongst other things) Local Eyes, and I have got lots of cool things I want to add to it, such as Instagram integration.
If you have any comments on Local Eyes, please let me know. But also, bear in mind, I have so far only spent 12 hours on it, working by myself and I dont claim it to be worth $41M ;)
So after Heart & Sole, I decided to start up a new blog. The focus of my new blog was all the new javascript toys that have been bundled with HTML in w3c’s HTML5 spec.
Each day, for 10 days I will be publishing a blog post, with an introduction to the new toy, a short guide to implementation and some sample code, often accompanied by a lovely demo :)
So far this week I have written about (and played about with)
The ones I still need to write / code up some demos are:
- Device Orientation
- Online / Offline events
- Drag & Drop
- New Query Selector Benchmarking
- Audio / Video Manipulation
- Canvas
After the 10 days, I have a few other APIs I want to play with, so will write the blog posts as and when I get round to it.
Also, dont forget that all my code is available on github.
