31 Weeks of Windows Phone Design Index

In this post we’ll try to answer a very common question that developers and designers ask us all the time and that in fact we in the Studio try to define always when exploring new features in Windows Phone: Should we use a Panorama? Or a Pivot? Or a Page?

First I will start by saying that it is not Panorama OR Pivot OR Page. It is more like Panorama(s) and/or Pivot(s) and/or Page(s).

When I first started working on Windows Phone I had a wrong perception.  I’ve found this wrong perception also in many other developers and designers throughout these months. The perception many times is that you have to choose one out of these three screen types for your application. False. Windows Phone apps are made out of a collection of screens of different types that are interconnected. So Windows Phone apps are made out of a number of Panoramas, Pivots and Pages. It’s not OR, it’s AND/OR.  In Expression Blend and Visual Studio you can create a new Windows Phone project with a Panorama or a Pivot but it’s just the starting point - from there you can add a number of Panoramas, Pivots or Pages.

Could you have apps that needed only one single Panorama? Sure (i.e People Hub although it has so many connections to other parts of the phone like contacts list, settings etc - that’s it doesn’t feel like a “one panorama” app).

How about a single Pivot? Yes (i.e. Twitter app - kind of, although even that one has orbiting pages around the main Pivot).

How about apps made out of a single Page? Yes. But it is not common.

The large majority of apps are made out of a healthy mix of many screens of different types, Panoramas, Pivots and Pages.

Defining what types of screens to use depends on the Information Architecture (IA) of your app. We will get deeper into IA in the next couple posts so for now let’s try to define a series of guidelines (or rules when possible) to know when to choose one screen type versus the others.

During the tour last Fall I came up with the following statement that I think exemplifies the current ‘state of the union’ in the Windows Phone Marketplace:

“Panoramas are overused, Pivots are misused, Pages are underused.”

As we mentioned before, the choice of using Panoramas, Pivots or Pages is directly influenced by the IA in your app. Here is a quick guide to pick Panorama, Pivot or Page depending on your information needs:

Panoramas are for content consumption.

Pivots are mostly for content consumption and in some cases for content input.

Pages are for one dimensional (one view) content consumption scenarios (whether lists or video, audio, images/photos…), great for content input and great for content generation.

Panoramas

“Panoramas are like Magazine Covers. They expose only a few top pieces of content.”

Panoramas are gorgeous! Why wouldn’t we use them? Every Windows Phone app needs at least one or more Panoramas! - Wrong. Panoramas are gorgeous yes, they leverage the Light, Clean, Open, Fast Metro Design Principle. They are designed to make the user feel like they are dealing with content that spans beyond the physical borders of the phone itself! - content peaking communicates continuity in a beautiful way tempting the user to swipe to the left or right and discover more content. The parallax animation effect where the background of the Panorama moves a bit slower than the content floating on top of it (basic animation principle to convey depth used since early animation studios) makes panorama an immersive adventure.

Panoramas rock, and because they are awesome we tend to overuse them.

Here are some guidelines for when to use and when not to use Panoramas:

Panorama(s) are the “Magazine Cover(s)” of your app. They display only the top or featured content for users. They expose a sneak peak. Not all the content - just those top headers and articles. It’s just a sample of the goodness of your app - not your whole app! Panoramas display a summary of the functions and content available in your app. Literally think of them as magazine covers. To design Panoramas, think of them as full spreads of content, not as single Pages but as a whole large spread. It’s fun to design. Want to get inspired to design Panoramas? Explore some popular and well design magazine covers:

Windows Phone apps do not always require of a Panorama. There are apps that use no Panoramas and that’s just fine.

Panoramas can’t hold large amounts of data. For performance and experience reasons do not use Panoramas if you have the need to present a large amount of content for users. How much is too much? In general stay within 3 to 5 Panorama panels. Use ListBoxes that use a maximum of 15-20 items. Panoramas are not virtualized (memory managed) so think of them almost as big flat images than dynamic content controls (like Pivots). Again, they are more of Magazine Covers - beautiful and immersive.

Panoramas are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Panorama. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Panorama.

Leave Panoramas for the end of your design process. What?! Yes! J I realized that Panoramas are better designed and more easily laid out when you leave them to the end. This is contrary to what I did initially and what I’ve seen most people do. It’s even contrary to what Visual Studio promotes but trust me, leave Panoramas to the end. Panoramas expose only the top/featured/most recent pieces of content of your app - but you cannot define what top/feature/recent content to display in your Panorama until you have not nailed down the full extent of your IA and the rest of your app including Pivots and Pages. Creating a Panorama once the IA and flow of your app have been defined (including Pivots and Pages) is the way to go and makes your Panoramas more streamlined, better designed and more efficient. You can certainly decide or define you will need one or more Panoramas early enough in the process - go ahead and include them in your application flow - but do not go ahead and design them just yet.

Pivots

“Pivots are data friendly. You have large lists of information to present to the user? Use Pivots, not Panoramas.”

Pivots tend to be misused. These are powerful, horse power controls that have the ability to present and handle large amounts of data. They are virtualized so their performance is much better and optimized for handling large amounts of data compared to Panoramas. Pivots are best friends with ListBoxes (or ListView) controls. Many times we see us trying to use Panoramas (because of their cool, immersive value proposition) when we should be using Pivots.

Pivots help you present lists with information from the same data source but sorted out in different ways. Pivots have Pivot Items. Each of these Pivots Items can present information from the same database but sorted out in different ways. For example in these two cases we have two different Pivots. The first one shows golf courses presented in three different Pivot Items, one shows Recent golf courses, next shows nearby golf courses, the third one shows all gold courses available. So, all are golf courses but we present them in 3 different ways. Also notice that we present information from the same database in completely different ways. Notice how nearby courses use a map and highlight data related to location, where recent shows a list in chronological order and displays the date when we last played in that golf course.

Pivots are not best friends with ‘draggable’ controls or objects. Sliders or other controls that have a draggable function can interfere with the swipe gesture in a Pivot. If you require of input controls that are draggable it is better to pop out a Page, have the user make input there and then return them to the Pivot.

List view design is fundamental for a great Pivot experience.

Pivots can also be used for displaying completely unrelated information between its different Pivot items. For example Settings. Think of this metaphor as application tabs.

Pages

“Pages are best for content input and content generation. ”

Pages sound kind of boring - no parallax effect like in Panoramas, not immersive, not feeling like they span beyond the screen borders - just a plain good old static screen. This perception is what drives many of us not to use Pages enough and instead force functionality into Pivots and Panoramas even when these are not needed.

iPhone and Android apps are naturally driven by single static pages. It is the task of the developers/designers to create immersive experiences within these page boundaries. In Windows Phone, with Pivot and Panorama as strong and exciting UI metaphors, it is easy to forget that Pages, like in iPhone and Android, are still super important and can help us solve many scenarios.

Pivots and Panoramas are great for content consumption. Pages are best for content input and content generation.

Pages are the best for receiving input from users. Think of a calculator (multiple buttons), forms that users will fill out with information and other heavy input scenarios. Perhaps configuration or settings and other scenarios with a number of input controls like sliders, text boxes, checkboxes, radio buttons.

Pages are great for content generation. Think of note taking apps, drawing or sketching, chat or communication apps and games as well.

If you only need to present a set of data without multiple views use a Page. If you need multiple views, a Pivot might work much better, or a Page linking to other Pages.

Pages are great for showing details of a previously selected item in a list or another object in a Panorama or Pivot.

Pages are like pawns in chess, there are many of them, they are usually not the star the show but, they are essential for an app to function.

Next Post | #6 Translating Information Architecture into a Windows Phone Application FlowNow that we have learned more about application flow and choosing the right screens, Panoramas, Pivots and Pages for our apps, we are ready to get deeper into Information Architecture. In the next post we’ll learn more about IA and how we can translate it to Windows Phone Design paradigms.

Advertise here with BSA

Icons are a very important element of web design and play a big role in a website. Designing the perfect icon is definitely a challenge and is always good to have resources and tips in this matter. Today we decided to gather a few Icon Design Tutorials to keep your ideas flowing and to increase your resource library. From new and fresh tutorials to a little bit older but still classic ones, you will find a lot of tips and inspiration in this list, enjoy.

Create a Mobile App Icon in Photoshop

Design a Detailed Audio Receiver Icon in Photoshop

Create a Detailed Camera Icon in Photoshop

How To Draw a Vintage Polaroid Camera Icon

Create an Electrical Outlet Icon in Photoshop

How to Create an Envelope Icon in Photoshop

Create an Apple Safari Icon in Photoshop

Create a Mac Style Home Icon in Photoshop

How to Draw a Shopping Bag Icon in Photoshop

How To Create a Vibrant Cloud Icon in Photoshop

Design a Sleek Google+ Icon

Create a Cardboard Box Icon in Photoshop

Carbon Fibre Style Metallic Icon Design

Learn To Create A Glowing Google Plus Icon/Illustration

Stylish Metallic Button in Photoshop

之前只有用到 C99 的 loop initial declarations (在 for 的初始化部份宣告變數), 看 Scott 提到才知道有其它好東西, 順便來掃一下 C99 的功能

stdbool.h

定義 bool、true、false, 實際上是將 bool 對應到 C99 定義 _Bool

stdint.h

定義了整數範圍、int16_t、int32_t、int64_t 等型別, 再也不用查 short/int/long 等在 32/64 bit OS 上的大小為多少。

designated initializers

可攜又易讀的初始化 (ref.)

// array
int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
// struct
struct point { int x, y; };
struct point p = { .y = yvalue, .x = xvalue };

像要用建表實作 isspace() 的話, 這樣寫超清楚的:

bool myisspace(int ch) {
    static bool whitespace[256] = {
        [' '] = true, ['\t'] = true, ['\f'] = true,
        ['\n'] = true, ['\r'] = true
    };

    if (ch < 0 || ch >= 256)
        return false;
    return whitespace[ch];
}

其它

像 snprintf、inline、variable-length array (例如 int array[n]) 也很實用。

According to the almighty Google, bounce rate is defined as “the percentage of single-page visits or visits in which the person left your site from the entrance (landing) page“. Basically, those users who leave your site right after they hit it — without checking anything else out. Bounce rate is a true measure of your site’s engagement. There are a bunch of factors that are involved with a lowering bounce rate, the main one being having relevant content, but even relevant content doesn’t stand a chance with a very poor web design.

Truly, the real killers of engagement are distractions and annoyances. As a whole, anything that the user gets distracted with or annoyed by will drive them away. Distractions can be anything from an overuse of animations to a blinding color scheme. Eliminating distractions will keep users focused and engaged on the content and purpose of the site design. Annoyances are just those elements that irritate users like poor navigation, error messages and unreadable typography.

A properly designed site can reduce bounce rate and increase engagement significantly. To avoid going into crazy detail about proper web design, I’ve tried to boil down how design elements can directly lower bounce rate and there are really six elements that go into reducing bounce rate:

• Good UI
• High Quality, Relevant Imagery
• Engaging Color Scheme
• Readable Type
• Consistent Branding
• Responsive Feedback

1 – Good UI

The quickest way to annoy a user is to design a site that has an unusable or bad user interface. Start at the top with the sites main navigation; design the site navigation to be easy to use, make sure labels are clear and easy to understand. Also, make sure that your navigation is simple and not cluttered with unnecessary stuff.

Positioning of typical site elements should be predictable and easy to find. Search boxes, navigation, logos and social sharing buttons should be positioned in typical and predictable places. If a user hits your site and can’t find these basic standard elements they are more likely to jump.

Forms are often a huge culprit in high bounce rates. Design your forms so that they are quick and easy to complete. Like navigation, make sure labels are clear and easy to understand and use form colors that engage the user. Breaking up long forms into multiple, smaller forms and letting the user know where they are and how much further they have to go, reduces bounce rates also by keeping the user engaged.

2 – High Quality, Relevant Imagery

For some reason, it seems like it’s always easy to spot stock photography. Maybe it’s because most stock photography is cheesy (you know, everybody is always smiling into the camera) or maybe it’s because the user just saw the same girl on three different billboards on the way home from work.

When users see and recognize general stock photos they tend to feel like the site is fake or cheesy. Relevant photographs let the user know that you care about the experience and that you want to show them what is important to you. Also, bad photos — even relevant ones — can drive the user away for the same reason. Great photography is always a wise investment. Hire good photographers to take product, location and staff images.

I don’t mean to demean stock photos, I actually use them quite a bit. Just make sure to choose relevant, non-cheesy photos that will not distract or annoy your user. Also, color correct those stock photos to blend in better with your sites color scheme. This will allow those photos to feel more relevant to the site even if they are just smiling, happy, thumbs up style stock photos.

3 – Engaging Color Scheme

The only thing worse than auto-start audio and video is an obnoxious, blinding color scheme. Unless your designing a children’s site, super bright color schemes are just simply annoying and will kill your bounce rate. I don’t know about you, but when a web site loads and I have to quickly squint and turn down my display brightness I’m usually gone fairly quickly there after.

Design and create a color scheme that complements your content. Your color scheme doesn’t always need to be soothing blues and greens, but it needs to be appropriate to what the site is offering. If your designing a health food site, go ahead and use the blue and green but if you are designing a motorcycle site you may want to consider silvers, reds and yellows on darker backgrounds. One thing I also try to do is pull color schemes from products, logos or imagery provided by the client.

Another important thing to consider when choosing an engaging color scheme for your site design is to check out the competition. See what color schemes they are using. Chances are, if the site has been around for a while they’ve done some bounce rate testing themselves and may have figured out some color schemes that work better.

4 – Readable Type

This is a no brainer when designing for lower bounce rates: make sure the user can read all the headlines, paragraphs and links clearly. Choose legible fonts that can be read quickly and easily. Make sure font colors are easy to read — don’t use a pink font color on a red or orange background for instance. Fonts, font colors and font sizes are critical to readability; scripty and handwritten fonts are bad ideas for long paragraphs or smaller sized text. Use appropriate headline and paragraph font color and sizes so that the user feels comfortable and doesn’t have to strain their eyes to read.

Proper letter and line spacing is also important to readability. If characters are squashed together it’s harder for the user’s eyes to distinguish each letter. Generally, you don’t have to worry about letter spacing if you are using standard web fonts. Line spacing, especially in large paragraphs, is very important to readability. Make sure hanging characters don’t hang down and overlap other lines of text or that bold text doesn’t shift the line height up or down creating a weird, eye catching negative space between lines.

5 – Consistent Branding

We already talked about engaging color schemes, but another element that goes hand in hand with this is consistent branding. Colors, logos, types, links, buttons, inputs, selects, backgrounds: all go together to create a consistent branding or theme. Users tend to bounce if things start to get cluttered or disconnected and branding your website is probably the best way to combat this.

Along with making sure logos are present on all pages and that color schemes flow throughout, keeping the same formatting from page to page will also help to enforce your brand. Keep the same content and side bar widths, keep the background colors and textures the same throughout and also keeping headers and footers the same throughout will help lower bounce rates.

Headers and footers are great ways to brand the design and keep users around. Not only do they offer a simple way to keep consistency, they offer a vehicle for consistent colors schemes and logos to be displayed — oh, and they also generally contain most of your sites’ navigational elements too.

6 – Responsive Feedback

The last key element in engaging your users and keeping them hanging around on your site is to make sure you give the user feedback. Not necessarily encouraging words, but direct feedback as they move around the site. Design good hover states for links and buttons to let the user know things can be clicked on. Navigation between pages and links between pages should give clear feedback that they can be clicked and used to go to other pages.

Besides hover states, give users clear instructions on filling out forms or any other process and let them know when they have accomplished a task. Well designed error states are great at reducing bounce rates but simply having an error state may actually increase frustration and irritation. When using error states, try to give the user instant feedback right there in the input field. Avoid the error pop ups after the user clicks the submit button.

Be positive with your feedback. If you are using messages to guide or instruct the user through a task be positive with your messages. Avoid messages that use words like “error”, “wrong” or “must” and try to use a more positive, natural and human response that won’t make the user feel like an idiot. If the user is treated like an idiot they are bound to jet — just like most of us do when a smarmy used car salesman insults our intelligence by trying to sell us an extended warranty.

Conclusion

Bounce rates are important to any website and it’s not just for the SEO or marketing guy to worry about. A major portion of why users bounce is directly related to the design and experience of the site itself. Whatever you do, just try to avoid using anything annoying or distracting and make your designs inviting and comfortable for the user.

View demo Download source

While CSS3 allows us to rotate letters, it is quite complicated to arrange each letter along a curved path. Arctext.js is a jQuery plugin that let’s you do exactly that. Based on Lettering.js, it calculates the right rotation of each letter and distributes the letters equally across the imaginary arc of the given radius.

How it works

The main idea behind the Arctext plugin is to rotate letters with CSS3 transforms in order to place them along a curved path. The curve is always a segment of a circle (hence arc) for which the radius can be specified. The space and rotation for each letter will be calculated using that radius and the width of the text.

Options

The following options are available:

radius        : 0,
// the minimum value allowed is
// half of the word length.
// if set to -1, the word will be straight.

dir                : 1,
// 1: curve is down,
// -1: curve is up

rotate        : true,
// if true each letter should be rotated.

fitText        : false
// if you want to try out the
// fitText plugin (http://fittextjs.com/)
// set this to true.
// Don't forget, the wrapper should be fluid.

View demo Download source

Advertise here with BSA

From print to packages to web design and pretty much all other media that you can think of, typography always plays a big role. Not only can good use of typography add to your design from a visual standpoint, it can also play an important role in defining the heirarcy of the content. With this in mind, we gathered a collection of inspiring typography usage in web design. From small type to huge and colorful ones we will show you that typography can be very important in your design.

Life in Greenville

Cider

Circles – Meetups for the Creative Types

goodness

Yes Nurse

Viljami Salminen

unify

senic

7 Days in Havana

Planilandia

Captain Dash

inTacto 10 years

Nike Chosen Series

Hello Bar

Build Responsively

Roberto Paganelli

koppy

255 Creative

Haus of Design

Headset Press

deciduous

Source:

The Best Designs
CSS Design Awards

31 Weeks of Windows Phone Design Index

Introduction

Today we begin our preparation to get ourselves ready to define the Information Architecture (IA) for our app. We will discuss Information Architecture more in depth in a future (not too far away post) but first I want to touch on a couple concepts that I think are critical for us to be able to visualize in our mind how a Windows Phone app is structured. With this knowledge in mind plus the IA for your app we should be in a good place to move forward in the design process. The first concept I want to talk about is Hub & Spoke Navigation Model and the second one is Choosing Between Pivots, Panoramas and Pages. This week we will cover Hub & Spoke and next week we’ll go into the choosing the right screen patterns for your apps.

The Hub & Spoke navigation model or “distribution paradigm” is not exclusive to Windows Phone. It is a widely known model used on website navigation and structure as well as in other digital interaction mediums. The Hub & Spoke model is particularly popular outside the digital realm and widely used in transportation, telecommunications and urban design. One of the best examples are airline route maps.

Wikipedia defines the Hub & Spoke Distribution Paradigm as “a system of connections arranged like a chariot wheel, in which all traffic moves along spokes connected to the hub at the center.”

While working on this post I came across Paul Laberge’s Going with the Flow… Using Metro to Control the Experience article and I must say he covers almost everything I wanted to cover here . Paul does a great job of highlighting the top concepts related to Hub & Spoke navigation in Windows Phone. To avoid duplication I will refer you to his article and instead will spend some more time here covering examples and other in depth guidance on Hub & Spoke. Make sure you read Paul’s article.

The reason Hub & Spoke is important in Windows Phone is because it helps you define the flow of the application, or the flow of the experience as Paul describes. When working on a Windows Phone app the flow is the first thing to nail down - not the visual design.

The Hub & Spoke navigation model is ideal for small digital devices, like phones, where screen resolution is limited and small but where content is still a lot to deal with. Here is a typical side to side scenario between Windows Phone Hub & Spoke and iPhone/Android non-hub and spoke models.

The Backstack

A fundamental concept in the Hub & Spoke model in Windows Phone is the “Backstack”. The best way to describe it is with breadcrumbs. As in Hansel & Gretel breadcrumbs J Once upon a time Hansel & Gretel where navigating happily through a dark dark Windows phone app (with black background). Every time they went to a new screen they’d drop a breadcrumb there so they knew the list of screens they’ve been to. They went on and on until they found a little house where an old lady invited them in offering ice cream sandwiches and apples. Luckily in this version of the story Hansel & Gretel were smarter and they decided to go back home. The list of breadcrumbs they dropped helped them return back where they came from.

In a nutshell, in Windows Phone the user taps objects, buttons, list items, icon buttons in the app bar or other user interface controls to move forward in the app structure. Basically, the user moves forward by making decisions.

The user moves backward in the app structure by using the back button… the user moves backwards by instinct and memory. The back button is used “blindly” by the user and the user learns to trust the back button. From this point of view the breadcrumbs analogy actually works only for the developer of the app. The user doesn’t have a visual map that tells her where she is going to - she just knows she is going back where she came from.

This is the reason why handling the Backstack correctly is so important, because the user will use the back button with only her memory as a guide. It is also the reason why starting to define the right app structure early in the design process is fundamental for the long term success of the project.

Removing Steps in the Backstack

Sacrilege!? No, not really… in fact, you as the developer or designer are responsible for removing steps from the backstack if needed and whenever it makes sense. I was first introduced to this concept by Corrina during the Windows Phone Design Day tour last Fall. In her REFINE session she provides some really good example of when it makes to remove steps in the backstack.  At first I would have though the backstack is untouchable since we want to respect a user’s path but there are different scenarios when it is convenient to remove items from it. In this example Corrina explains that it obviously doesn’t make sense to have users return to the credit and billing screens once the purchase transaction has been completed. Instead when pressing the back button on the last screen the app would take the users back to the wish list.

In this other example we can see an opposite scenario where removing search and results from the backstack could cause confusion for the user. The user is in a wish list, searches for products, finds some products and adds one to the wishlist. From this last screen it makes sense to send the user to the search results screen (the previous one) since she might be interested in adding more items from the same results instead of going all the way back to the wishlist and having to perform perhaps the same search again. So you can see how in different scenarios, it makes sense or not to remove screens from the backstack.

Here are some additional tips that Corrina shared with us during the tour:

“Remember, back means back; not forward, not sideways, but back.”

“Ensure application state is persisted appropriately.” 

“Ensure transient interface elements do not appear in the back stack.”

Diagraming the Hub & Spoke Navigation Model for your App

Here are a couple methods to diagram the flow of your app and how the Hub & Spoke model will get to manifest in it. Please note these are techniques for illustrating diagrams and not methods for defining your app flow. Your application flow can only be defined later in the design process when you start exploring and maturing the Information Architecture.

Abbreviated Nomenclature

This method is quick. It’s great when quickly wanting to convey an idea of flow to your peers - other designers or engineers. You can use this by sketching it with pen or pencil or using some of the visual assets in this Expression Design file or Adobe Illustrator file. It consists of drawing circles with abbreviations as follow:

Start - Windows Phone Start Screen

Pv - Pivot

Pa - Panorama

Pg - Page

Visual Nomenclature

This is a more detailed nomenclature that allows you to convey visually the key elements or screens in your application flow. I’ve created some Expression Design and Illustrator templates for this nomenclature if you want to use it with your favorite visual design tool. You can also sketch this out. Here is a way I do it that uses just a few strokes making it as easy and quick as possible.

Learn More about Hub & Spoke Navigation Model in User Interfaces

This is Paul Laberge’s article on Hub & Spoke model in Windows Phone. Also, here is the Navigation section in the Windows Phone UX Guidelines which describe Hub & Spoke in more detail as well as explains some other concepts like Tombstoning.

A good way to understand Hub & Spoke is to explore alternative navigation and information architecture models. Also, Tombstoning is an important component of the Hub & Spoke navigation model as it allows application to persist their state even when users have moved beyond our outside of it. Escaping Navigation Hell by Like W is a great article that describes specific techniques to craft experiences where content is a lot and complex - while this usually drives for an also complex navigation mechanism, Luke provides shares some tips to tackle down navigation (or not to at all! J).

Finally if here is the obvious Wikipedia page for Hub & Spoke as well as the Infragistics Quice Design Pattern page for Hub & Spoke (worth studying for other common navigation design patterns).

Next Post | #5 Choosing Between Panoramas, Pivots or Pages

In our next post we will review the criteria to decide when to use Panoramas, or Pivots or Pages. We’ll demystify the use of some of these screen patterns.

More than a year ago, in my very first talk at Web Directions on Active Web Development, I had this slide:

The intention was that within organizations web developers work to keep an updated list of html5 features that they would adopt or not. However, Paul Irish and I thought it would be useful if there were a global set of recommendations that web developers could consult and tap on when they are deciding on how to use features. This was the seed for the creation of HTML5 Please.

When can I use and Modernizr do a great job in informing the users of available features and how to feature detect them. The Modernizr polyfill wikipage also does a good job of listing all the available polyfills. What we felt missing was the glue that bound all this information together, to tell the user what the best tool for the job was: either on its own, or with a polyfill or a sensible fallback.

With HTML5 Please, you can just search for a feature that you are looking to use and find out how to do so. If you think our recommendation is incorrect, you can edit the recommendation for each feature and send a pull request (like this example).

The Setup

Initially, this data was in JSON file that was manipulated in node to generate the static html. Soon, it became obvious that JSON would be a big pile of mess when many people manually update it. Also, it was clear we needed a build system, which is where Tim Branyen stepped in to help creating one using node and backbone that would combine markdown posts into a single HTML page.

It was also obvious that we needed a good system to create these markdown posts so that each of the tags that are used in the ‘Explore features’ section are not created accidentally (e.g. prevent creating a tag called polyfill instead of polyfills). To do this, Deepak Jois created a simple shell script that accepts a feature name, its associated tags, its kind, and then creates a markdown file with these details and opens it in your editor.

We also wanted a way for users to help us make the content better. I added a link to the markdown source on github for each feature which the reader only needs to fork, edit and send pull request for (all over in two clicks!).

The Front End

I was unsure of how to proceed with the design. This is how it looked like at the beginning:

Over the last month, I tweaked the design majorly to more or less match what you see today. I also wanted to use Sass more, which is why the source stylesheet is all Sass.

It was awesome to work with Paul, Tim, Deepak, Connor, Brian Blakely, Addy Osmani & many more to create this site. Please let us know on Github if you find issues or if you have ideas on how it could be better!

JavaScript 的物件並沒有封裝的概念，所有綁在該物件上的屬性都是外部可見的，不過還是有辦法做到物件封裝的效果，那就是 Module Pattern，作法很簡單，想要保持 private 的私有屬性就宣告成建構函式的區域變數，在建構函式的最後回傳一組你要保持 public 的屬性或是 method，範例如下：

function Person(age, gender) {
    var _age = age || 16,
        _gender = gender || 1;

    return {
        getAge: function () {
            return _age;
        }
    };
}

這個範例中，age 和 gender 就是私有屬性，在 Person 物件外的操作無法碰到它們，唯一可以做的事情就是用 getAge 來讀取 age 的值，就這樣，我們有了有封裝特性的模組，不過在實際的應用的時候，還有一些問題需要處理，首當其衝的，便是模組之間的相依問題，不管你的程式架構多好，使用了各種設計模式來減少相依性問題，一定還是會有相依性的問題存在，在 server side 的 JavaScript 應用中，模組的相依問題還不明顯，因為你需要的模組都應該在本機系統存在，你的程式才能執行，以現在最熱門的 nodejs 來說，用的是 CommonJS 定的 Module/1.0，只要把要匯出給其它人用的介面指派給 exports 這個變數，其它程式就可以很簡單的用 require 來取得，程式運作的流程就是很線性的從第一行跑到最後一行下來。

在網頁上的應用多了一個可能的變化，就是為了效能考量，讓一些資源像是 CSS、JavaScript 等檔案用非同步的方法讀取，這時候如果程式需要的模組檔案還沒讀下來，就還會有非同步執行的問題要處理，雖然 XMLHttpRequest 可以使用同步執行的方式，但是這樣會把整個瀏覽器定住，使用者用起來會覺得瀏覽器死當完全沒反應，所以這種作法完全不列入選擇之中，也因此有了 AMD 這個非同步模組的規範，它的寫法也很簡單：

define('moduleA', [dep1, dep2], function (export1, export2) {
    //do something..
    return {
        method1: function () {},
        method2: function () {},
    };
});

define 是一個全域的函式，專門用來宣告和註冊模組，它吃三個參數，前兩個都是非必要的，第一個參數是模組的名稱，其它模組如果有需要用到這個模組的話，就會用這麼名字來相認，第二個參數是一個字串的陣列，內容是需要的其它的模組名稱，第三個參數則是模組的建構函式，建構函數的參數則是根據前面第二個參數設定的相依模組來決定，會照定義順序傳入相依模組輸出的介面，而模型的建構函式最後面還需要回傳一個給其它人使用的介面，和 Module Pattern 一樣，其實背後的設計就是把建構函式當成相依模組建置完成的 callback function，所以就可以確保相依模組可以非同步的動態讀入，都準備好了才進入下一步。

AMD 最有名的實作就是 RequireJS 了，它完整實作了規範沒有講到的，瀏覽器動態且平行的讀取遠端主機上的檔案，用正確的順序執行，然後還把每個模組輸出的介面都管的好好的，不過其實 RequireJS 還提供了更多功能，像是作為 reousrce loader 來讀取 JavaScript 以外的資源，配合 plugin 可以直接寫 CoffeeScript 不需要先 compile 好，還有 optimize 和 uglify 等 deploy 相關的機制，讓開發環境和正式環境的接軌變得容易許多，不過上面講的都是優點，其實 RequireJS 還是有些缺點的，其中最大的問題就是文件條理不好，會讓把環境和設定搞起來這件事難度增加許多，再來是除錯變得困難許多，像是用 CoffeeScript plugin 即時編譯的話，剛好其中一隻 coffee 檔有語法錯誤，那會變的很難除錯等等，至於是利多還是弊多我覺得是利多，大部分的問題都是搞清楚就好了，CoffeeScript 的錯誤也可以用編輯器外掛來找。所以最後結論，我是蠻推薦可以導入 AMD 到中大型的 Web Application 專案的。