Wikipedia defines style guides as a set of standards and rules for designing and writing documents with the purpose of providing uniformity in a specific publication or organization.

In the context of web development a style guide usually defines what CSS styles and UI widgets are available, where to use them, and if any special markup is needed to create them. A typical guide would list the available styles and widgets on a page with corresponding HTML markup next to them.

One example of a style guide that people are probably familiar with is Twitter Bootstrap’s documentation. The documentation is extensive and shows how your basic HTML elements are styled along with different CSS modifiers that can be used with each element. Twitter Bootstrap’s components page adds reasoning for when to use a given component – useful if you’re designing your UI as you go.

Create the Style Guide First

Depending on the project you might find yourself with a set of .PSD layouts from which you are supposed to build a site. (This is pretty much the state of business in Finland.) From here your first step should be gathering a list of UI elements and colors found in the layouts and creating a style guide. Why?

• Providing one centralized location for styles early on prevents you and your team members from re-creating common elements. A breadcrumb element should only have one implementation and one styling.
• It’s easier to find rarer UI widgets if they are all gathered in one place. This saves developer time from finding and reverse engineering existing UI elements.
• Single elements can have multiple variations based on context. For example, a button element could be green if it’s a primary action button, while secondary buttons are grey. Each button might also have a disabled state, in addition to the default active and hover states. Displaying all these states in a page makes debugging them easier while at the same time reminding people to use button.primary instead of creating their own button.blue or whatever.
  
• In the case of implementing .PSD designs the style guide can be used as a tool to communicate back to the designer and show how the widgets behave in real life
• Later on in a project the style guide can help you refactor your styles in a similar way that unit tests help while refactoring code. Global style changes can be scary but a single glance of your style guide page should tell if you actually broke something.

Start easy

A style guide doesn’t necessarily need to be as complex as Twitter Bootstrap’s guide which is intended for quite a wide audience. If you haven’t done style guides previously, a simple HTML page with examples of your UI is a good place to start.

In a recent project we hand coded a simple page with all available UI widgets. Granted the page probably could have used code examples, and it was sometimes left broken, it still proved useful for communicating what was available and testing the widgets.

Automate

In larger projects it might be worthwhile to use a tool that builds and updates the style guide automatically. Kyle Neath’s KSS uses machine readable (but simple) CSS comments to describe different elements and their variations. It also gently pushes you into writing modular, object oriented CSS. An example of KSS’s end result is GitHub’s own style guide. KSS does work with the popular CSS preprocessors SASS and LESS.

Another approach is Adactio’s Pattern Primer which is basically a simple PHP script that collects a bunch of HTML snippets into one guide.

Having the style guide update automatically makes people trust it’s always up-to-date and makes it easier to integrate in the development process. But it doesn’t mean the manually updated guides would be somehow useless. Every widget needs to be coded and every style defined so why not do that on one page? In the end it saves everyone’s time and trouble and enables them to focus on creating kick-ass services instead.

I joined the company as Head of Technology and will be actively communicating the exciting things we have cooking in our web app projects.

Cutting to the chase, I wanted to share updates of an exciting couple of days working with Microsoft and a few potential clients, ironing out our readiness to deliver awesome content for day 1 availability in Windows Store.

We had a great day with Microsoft yesterday evaluating our NewsFlux app prototype against their Application Excellence criteria. Juhani (@juhaniv) and Oliver (@_olli_) were excited to see a well thought out and high performing JavaScript Metro app. SC5 was happily granted the token for publishing content to Windows Store among the first hand picked companies. The screens below are from a version that doesn’t use the final data sources, just to make sure we don’t spoil the surprise.

I have to say I’m positively surprised how well Microsoft is guiding developers to create quality content for Windows 8. While the tech documentation is still a tad incomplete (something we’ll aim to help the community with going forward), the UX guides and especially the certification checklists provided by the Microsoft reps have been top notch.

Obviously our expertise in creating modern front end solutions pays off in ramping up Windows 8 content production. While optimal code and framework reuse between ‘vanilla HTML5′ (don’t bite on the term too much, think e.g. single page apps, with an MVC + UI + bells and whistles combination of your choice) and Metro JavaScript apps remains a study item for us and other pioneers, we’re pleased at how much we were able to do in just a couple of weeks.

So, full steam head. Some of the things we’ll be looking at next week is how to design compelling and very Windows 8 friendly UX paradigms with the semantic zoom concept. Additionally we’re thinking about efficient use of WebSockets to see if the performance of Metro apps especially in resource constrained devices (read future ARM slates in sub-optimal networks) could be given a boost.

Have a great weekend!

Our Jyväskylä office is located in the brand new Innova 2 building which offers a modern and ecological working environment. The workplace is just next to city center and public transportation and has a beautiful Lake Päijänne view.

We aim to build a team with 15 web technology experts in Jyväskylä. So we are continuously looking for senior developers to implement real-time HTML5 web and mobile solutions. Our client projects are an interesting way to learn new technologies but the tasks will demand a strong background of software development with some more traditional programming languages, like C#, C++, Java, .NET or Ruby. Any ICT talent with passion for new technologies will feel warmly welcome at SC5. We invest in employees education in new technologies and growth as professionals.

We take pride in disciplined and well-defined development. SC5ers are respected experts in web technologies. If you are interested in joining our growing team, please check our open positions and do not hesitate to leave a job application.

SC5 – a forerunner in web technologies

HTML5 is the fresh buzzword in the web world and we are proud to be one of the forerunners in the rapidly changing world, where new devices pop out every single day and web services must be usable in any place and time possible. Our senior developers are passionate about the latest web trends and that’s why it’s easy to claim that we have the best talent to build real-time, responsive web and mobile applications.

We will be very active educating the Jyväskylä region ICT field on latest web technologies. One of the concrete plans is to create a HTML5 mobile apps development course in co-operation with Jyväskylä University of Applied Sciences and other local players in the ICT field. We are also taking our HTML5-aamupala concept in some form to Jyväskylä. If you are interested in participating in these events, please leave me a message.

The operation of Jyväskylä Innovation supports the growth, development, and competitive strength of technology businesses in Jyväskylä and Central Finland. SC5 will be visible in their web site as in news and company gallery.

We are happy to be in the center of the growing ICT field in Jyväskylä region and are ready to give our effort to make it a world wide success story. That needs a lot of co-operation and hard work, so let’s roll up our sleeves and get work well done!

We feel we have learnt many lessons new to the community and that now is our turn to start contributing back. Expect us opening up in the near future: open sourcing both hacks and entire platforms, participating actively in online discussions, hosting events, organizing lectures in cooperation with schools, mingling in conferences etc.

As a small step for the tech community but as a giant leap for us we have decided to move from the local domain to SC5.io. This is part of our plan on tuning into the international tech community and calling it home.

Comments and feedback are well appreciated!

Ps. why .io? .io is on the rise in the tech startup scene as an alternative for dotcom. It has a hype’ish and rebellish reputation that we find fitting …and the dotcom was owned by an American holding company.

• 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.