• A release candidate will be launched in early June, after this the development API should be pretty frozen
• There will be a release to partners in Q3/2012.
• Public launch will take place in October or November
• Developers qualified by Microsoft will be granted exclusive publishing rights to Windows Store until the public launch
• Windows 8 Metro applications can be developed with the HTML5 stack, C# and C++.
• WinJS is the Javascript (HTML5 stack) framework for Windows 8
• Also ARM devices (tablets) will have the desktop side. Before there was discussion the ARM devices would only have Metro.
• Windows 8 currently supports three UI technologies: HTML/CSS, XAML, DirectX
• For an app to be accepted into Windows Store it has to support the Windows 8 special features: Snapped view, share and search (if applicable).
• Live tiles are an important part of the OS and an app can allow a user to add multiple live tiles, for example one per theme.
• Microsoft has produced an Azure based toolkit for easily handling Windows 8 notifications. Watch the intriguing video on how to enable push notifications in 3 minutes.

SC5′s spacious lounge was providently equipped with a large screen and a projector to enable all team members affectionate for ice hockey let their steam out when supporting a favorite team. Why go wrestle for a place in an overcrowded sport-bar when one can watch the games in the comfort of the company’s own office.

And while the scores may not always be in your favor, being in a fun and friendly team is definitely a win.

I thought this provides an excellent myth collection to go through.

1. HTML5 apps require more effort than native apps when software complexity increases

“At first things are easy. For simple screens, using a webview might be faster than writing a native implementation. As you add functionality to the webview, the complexity increases until you give up and write everything native.”

It’s a myth. A software’s capability to take complexity is an architectural issue. Neither technology stack here limits to any architecture.

However I’m very familiar with this sympton in real life. Many web developers start developing web applications without giving a thought to the app architecture. They miss the fact that an app requires a different architecture than an online service. You end up with loosely bundled pages with a lot of JS/AJAX glues trying to smoothen the experience. This leads to an unsustainable app architecture.

The first step is to divide the web technology based system into a client and a server – exactly like the native app based services are divided. Then you should design the structure for the client. What we do is we apply one of the many open source Javascript MVC frameworks out there to provide a clear structure to the client.

2. Using device features in HTML5 apps is problematic and requires extra development effort

“You could use an open source shell-app framework like PhoneGap, but that leaves you at the mercy of their schedule. If the native platform introduces a new API, or you run into an edge case that requires extending the shell framework, it could be months before you can implement your own app’s functionality. One solution is to start from an open source framework and maintain a fork when the need arises.”

Not true. There are indeed good open source containers like Phonegap. However not only they cover native features over a wide range of devices, they also provide you a plug-in interface that allows you writing any native code and hooking it to the HTML5 app. Windows 8 goes a step further and provides all the device features over a Javascript API.

In other words the existing containers have done all the dirty work and if something is missing, you can write it native.

3. Cross-browser issues make HTML5 inefficient to develop compared to native apps

“When developing a native iPhone app, the development cycle is: write a little code, run it in the simulator, and repeat.

Browser quirks live on in HTML5. Shell apps require you write a little code, run it on an iPhone simulator, an Android simulator, a Windows Phone 7 simulator, et al. Alternately, you could save cross browser testing for the end, but the risk is missing architectural mistakes until late in development.”

Doesn’t make any sense. First of all the development cycle usually is developing for one device initially and then adapting to others, similar to how online services used to be first written for Firefox and later adapted to Internet Explorer(s). There are no architectural mistakes that can occur late – if you have a proper architecture to start with.

Porting to different devices does take time and skill. To reach a proper user experience you have to know the perks of each browser engine. Use specific CSS transitions on iOS to tap into the hardware accelerated slides. Disable CSS shadows on Android because they are dead slow. Avoid slider components on Windows Phone as drag has a delay.

But this is very little effort compared to writing (and maintaining) an individual app for each platform.

4. Updates bypassing the app store cause versioning problems

“Shell app let you update content without requiring a full app release by serving your pages off a server. In the process, you lose release atomicity, the assurance that whatever you ship to clients comes in one complete, unchanging bundle.

Imagine 1.0 of your app has a red color scheme. Between 1.0 and 1.1, your company changes its branding from red to green. The new design touches both your web view and the native chrome around the web view.”

Absurd. If you have technically designed your app correctly, the whole user interface is in the HTML5 app. Thus there can be no versioning differences between the native UI and HTML5 UI. It seems we are hitting here again the ill-designed system where web pages are glued to make an app.

Overall you don’t have to use the hot updates, you can of course ship updates only with your container in native updates. However if you rely on the native updates in a system that has a server, now that’s where you will face serious versioning problems. Not all users ever update (if not forced to) so your server has to support also older clients.

In the end the hot updates are a thing that requires some thought yet they are pretty simple to manage.

5. Reaching a native user experience for all platforms is problematic

“Within a browser, users hold web sites to the standards of other web sites. Evaluated against native apps, shell apps have inconsistencies that make them feel wrong, even if the user can’t articulate the problem.

On iOS, the scroll friction for web views are different than native scroll views. WebKit delays taps to detect gestures. On Android, the web view may add decoration to link clicks. Platform specific quirks can be remedied, but it’s a matter of trial and error.

The harder problems are inconsistencies in platform conventions. The iPhone uses Helvetica as its system font, while Android uses Roboto. iOS transitions between views by sliding new views in from the right, while Android uses a zoom effect.”

This is partially true. You have to have a lot of experience (or time) to iron out a native-feeling experience. I think this is the biggest show stopper when new people start building HTML5 apps. We tackled this by founding a separate UX Developer role in our team that focuses on mastering these specialties.

Also it’s an unanswered question whether the HTML5 app should adapt to the devices unique look & feel or not. Windows 8 for one does not accept apps that don’t apply to the Metro design guidelines. These require work but in the end it’s mostly small layout adjusting.

6. HTML5 apps lack the performance required for native user experience

“Some software can succeed with poor performance. My go-to language for web app development is Ruby, which is slow, but a 60 millisecond difference goes unnoticed in a web app, where most of your time is spent waiting on the network.

For native apps, performance is critical to a great user experience. Users notice jerky scrolling, and performance can make or break a feature like a full text inbox search.”

Mostly a myth. (Ruby is a back-end technology so this again shows the system architecture has been wrong from the start.) It is true that as Javascript runs on top of the browser engine it by definition loses in performance native binary code. But note that this difference is not really what matters.

The performance problems are hit when the user interface is not smooth or does not respond to interaction immediately. These are issues related mostly to rendering and hardware acceleration. So how you render things is crucial. Furthermore trying to use the rendering methods that are hardware accelerated by the platform is important (such as the CSS transitions for slides in iOS).

7. HTML5 apps are solving the wrong problem

“Sometimes the ends justify the means, but the reasoning behind shell apps is generally flawed.

“We Need to Release Faster””

It’s a myth. HTML5 apps are actually solving the big picture. As I explained in my previous post the device spectrum is becoming fuzzy. Through Windows 8 the line between desktop and tablet is becoming unclear. Elsewhere Apple has artificially, yet successfully, maintained the device constraints very stable for the app developers. All the hassle with retina has enabled app developers to stick pretty much to one screen size. However Apple did not win entirely the ecosystem war and also they have to move on at some point.

Thus the question is: How do you build applications to people using hundreds of different devices on a number of different platforms with a varying range of capabilities? HTML5 apps answer this question.

The secret of success? Besides having a good number of high-profile clients, the company is doing a great job gathering the best professionals in the industry to be a part of its team.

Within the last two months only, SC5 troops were joined by a Senior Developer Eero Kurkela, a UX Developer Harri Kilpiö, a Developer Miika Aho, Sophie Rose as a Community Coordinator at the Helsinki office, and by a Site Manager Jarkko Tuomala at the Jyväskylä office.

Few more members are expected to reinforce the team later in May. Go SC5!

The current Content Management Systems are all about coupling back-end and front-end. It took 3 years for Drupal to manage 6.0 to 7.0 update, how long will it take for it to redesign its architecture?

The transition in CMS architecture that just needs to happen

The extra benefits of this kind of uncoupling to components is that you can switch the back-end without touching the presentation layer. On the other hand this allows developing new front-end applications and even opening your data to external services.

Avoid half way solutions and prioritize the uncoupling of presentation layer and back-end

Your content based service will no doubt still need a simple out-of-the-box system for non technical people to publish content. And actually the situation is not that bad. The CMSs will have hard time evolving but new uncoupled CMS will be born.

What to do if you have a ‘mobile emergency’ situation NOW in your CMS based service:

1. If you have muscle power or budget, produce a new responsive presentation layer and a REST API adapter between your current CMS and the presentation layer. Your presentation layer can be done future proof. When the new CMS arrive or old evolve (there is talk about Drupal 8.0 including a proper CRUD/CRAP API for content) you replace your back-end and keep on using your presentation layer.
2. If you have time, wait for the CMS to evolve. However note that in the end you might still be facing a large project in switching to a new CMS or upgrading your current.
3. The last, quick and dirty solution, is to start applying the hacks and extensions appearing to the most common CMSs. They add you partial mobile support, paged tablet experience and so on. However in most cases you will have hard time keeping your user experience consistent between devices and in the end you will face a transition to the modern uncoupled architecture anyway.

The device spectrum is becoming fuzzy

For which devices do you serve www.sc5.io and for which m.sc5.io? t.sc5.io would become also handy. What about Windows 8 tablet, transformer and desktop? Transformer gets t.sc5.io if it’s undocked? Man, you make no sense.

Responding to the end-device is more than just flexible layouts

Two key concepts in touch screen devices are the swipe and the slide. These are not supported by traditional online services, apart for the swiped vertical scroll.

Responsive design responds to the end-device capabilities to make the user experience feel native to the device. Yet while discussing responsive design most people refer only to layout adjustments through screen size based breakpoints.

Horizontal slides require a single-page-app architecture

The challenge with things such as horizontal slides is that the traditional web architecture doesn’t support it. Web is built around individual server generated pages.

How traditional web architecture is page bound and badly fits transitions

A solution can also be achieved with AJAX hacks to specific needs. But as a service becomes more complex and applies even more advanced features the AJAX hacks option becomes unsustainable. So a proper single-page-app architecture is the key to be flexible, future proof and to avoid the risk of bloating.

As Amit Runchal wrote, Apple’s ecosystem has become a repellent platform for app developers due to lack of transparency, “I know when I see it” rule policy and other arbitrariness.

Android is losing due to the fragmentation of the platform: both the varying hardware and the varying manufacturer distributions of the OS). Amazon has rocketed as a… marketplace.

Microsoft is abandoning its boat before it even left. Windows 8 Metro applications are HTML5-based. In other words they now bet on an ecosystem independent application platform.

When it comes to the end-users, they don’t care what ecosystem a gadget-to-be-bought belongs to – as long as it has the Facebook app, the Spotify app, the Skype app and so on.

And the application developers, they look for two things:

1. An efficient and future-proof application platform
2. A reliable channel(s) to reach the end-users and enable purchases

The core competence of an application developer is making great products. The rest is extra hassle. So a pie fragmented into ecosystems in both tech and distribution channel perspectives does not bring appetite.

I’m looking forward to Round 2: War of Application Developers.

Viestikapula tulokkaille kiertää seuraavasti:
Mikael kysyi Matulta mikä hänestä tulee isona. ”Olen isona lähempänä maalia, mutta perille pääsen tuskin koskaan.”
Matu kysyi Vesalta: Jos olisit eläin, mikä eläin et ainakaan olisi? Vesa vastasi: ”Onko kysymys faunasta? Hyttynen. Lapissa noita ‘kavereita’ riittää, mutta en ole löytänyt itsestäni sisäistä inisevää verenimijää.”
Vesa kysyi Petriltä: Jos sinun pitäisi kehittää uusi urheilulaji, mikä se olisi? 
Petri:
”Kun kengurunyrkkeily on jo keksitty, niin oma luomukseni olisi pandapaini.”

Matu, Vesa ja Petri esittäytyvät

Matu

Vesa

Petri

Mats ”Matu” Eriksson on talon uusi UX Developer. Aiemmin hän on suunnitellut ja toteuttanut pelejä sekä freelancerina ja eri firmoissa. Matua kuvaillaan ”hypersosiaaliseksi”, ja kommunikointikykyjen lisäksi vahvuuksiin kuuluu HTML/CSS/JavaScript/ActionScript. Vapaa-ajalla Matu harrastaa laitesukellusta, matkustelua ja ruoanlaittoa. Lopultakin firmassa on myös ammattimainen DJ!

Lapin kylmyyttä etelään paenneen Vesan erikoisosaamisalueiksi ja sydämenasioiksi on opintojen ja työkokemuksen myötä vakiintuneet konseptointi, käytettävyys ja sosiaalista mediaa hyödyntävät palvelut. Sitä kautta hän on myös päätynyt frontend-kehityksen pariin. Vesa odottaa SC5:ta yhteishenkeä, ketterää kehitystä ja turhan byrokratian täydellistä puuttumista. Vesa harrastaa matkustamista lähellä & kaukana ja uusista harrastuksista innostumista. Jälkimmäisen yhteydessä Vesa mainitsee mm. kameran, fivefingersin, molekyyligastronomian ja joogan.

Petri Mahanen on uusin kehittäjä SC5-tiimissä. Hän on kiinnostunut verkkotekniikoista ja käyttäjäkokemuksesta, hänen menneisyydestään löytyy webbisovelluksia, työskentelyä Teknillisessä Korkeakoulussa ja Unix-maailmaa. Petrin osaaminen kattaa koko webbistackin tietokannoista ja palvelimista frontend-kehitykseen, erityiset vahvuudet ovat PHP ja Zend framework. Petri harrastaa kaikenlaisia pelejä (lautapeleistä videopeleihin), japanin opiskelua ja on juuri aloittanut kitaransoiton opinnot.

”Todella mielenkiintoinen sessio ja aihe sai aikaan harvinaisen paljon keskustelua”, sanoo tilaisuuteen osallistunut Laura Avonius Fragitysta. ”Vaikka teema oli tuttu, esille tuli myös uusia näkökulmia. Esimerkiksi sisällön responsiivisuus oli uutta. Mielenkiinnolla odotan lisää esimerkkejä ja kokemuksia tältä saralta. Responsiivisen designin tuomilla uusilla innovaatioilla ja oikein tehdyillä palveluilla voitaisiin hyvinkin näyttää suuntaa myös kansainvälisesti ja osoittaa olevamme web- ja mobiilisovellusten kehityksen kärjessä”.

Tallenteet tilaisuudesta julkaistu

1.3.2012 Pyry Lehdonvirta – Responsiivinen Design from HTML5-aamupala on Vimeo.

Pyry Lehdonvirta SC5:stä selitti konkreettisin esimerkein mitä responsiivinen design tarkoittaa ja kuinka sitä voi hyödyntää: ”Responsiivinen design on sellainen design tai muotoilu palvelussa, joka muotoutuu käyttäjän päätelaitteen mukaisesti.” Ihanteellisesti yksi ratkaisu toimii kaikissa laitteissa ja laite toimii sen mukaan mitä käyttäjästä tiedetään. Esimerkiksi laitteesta riippuen yksisarakkeinen näkymä muuttuu kaksisarakkeiseksi, siirtymät ovat sulavampia ja sisällön määrä voi vaihdella. Sisällön responsiivisuus on maailmalla kiistelty aihe ja tämä herätti tunteita sekä keskustelua myös aamupalan yhteydessä.

Lopuksi Pyry nosti esille haasteet responsiivisen designin toteutuksessa. Päätelaitteiden erilaisuus, siilot suunnittelussa ja toteutuksessa voivat hänen mukaansa aiheuttaa huonon lopputuloksen. Suositeltava yhteistyö ja iterointi prosessin eri vaiheissa olisi paras tapa toteuttaa responsiivista designia.

1.3.2012 Janne Lohvansuu – Kehittäminen kokeilemalla from HTML5-aamupala on Vimeo.

User Intelligencen Janne Lohvansuun esitys käsitteli asiointipalveluiden kehittämistä kokeilemalla. Kokeilutalous on uusi trendi, joka korostaa vaihtoehtoisten lähestymistapojen hahmottamista kokeilemalla. Janne Lohvansuun mukaan kuluttajat eivät odota yritysten olevan virheettömiä. Hän kehottaakin rohkeasti lanseeraamaan tuotteita ja palveluita olemalla ”nysväämättä” liikaa.

1.3.2012 HTML5-aamupala – Paneelikeskustelu from HTML5-aamupala on Vimeo.

Paneelikeskustelussa mukana olivat Karoliina Luoto Sitrasta, Maija Savolainen Sanoma Magazines Finlandista ja Ming Lee Nokiasta. Aiheet vaihtelivat panelistien suhteesta HTML5-palveluihin ja päätelaitteiden konvergenssista aina priorisointiin kun tehtävänä on suunnitella palvelu yhteensopivasti tabletille, älypuhelimelle ja perinteiselle tietokoneelle. Eniten keskustelua herätti yhteistyö liiketoiminnan, suunnittelun ja tuotekehitystiimin välillä.

This post will cover in detail the HTML5 app (front-end). The big picture including the possible back-end is explained here.

Anatomy of a HTML5 app

As it turns out, HTML5 apps are really just about Javascript.

How to make the Javascript maintainable?

Pick a MVC framework (or build your own) to provide a clear structure for the Javascript code. Currently we prefer Backbone.js spiced with Require.js. However there are other potential options out there such as Ember.js, Knockout.js, Javascript MVC.

Another thing that could prove helpful is using CoffeeScript instead of Javascript. CoffeeScript is a more sophisticated language that compiles into Javascript. However it has not reached a de facto standard status so you should also consider the possible pitfalls.

How to efficiently develop a cross-browser, cross-device user interface?

Pick a UI framework which abstracts the UI elements and actions. We use JQuery Mobile most of the time, but also here there are a lot of potential candidates: JQ.Mobi, jQTouch, Sencha Touch and so on.

For the HTML and CSS work you should take a boilerplate as a starting point. A de facto standard seems to be HTML5 Boilerplate. It will save setup time from you and help smoothen cross-browser differences. Just remember to change that pink text highlight color so you don’t look as lazy as all the other people.

Future looks bright

All the popular technologies mentioned here are currently progressing very fast. In addition the open source community is constantly spawning new frameworks, tools and platforms. At the same time the device and browser manufacturers compete in browser speed and standard compliance.