반응형
https://github.com/component/component/wiki/Components

 

 

component module list - all the components

 

 

 

Components

This page acts as our "registry". When you add a component to this list it becomes automatically available to component-search(1) and http://component.io which are refreshed every 15 minutes. It'll also get tweeted by @component_js

The eventual goal of components is that you use only the pieces that you need, not large libraries like jQuery or underscore, these should be application-level dependencies, if used at all. However if you must use them for now, design your APIs in such a way that these are merely implementation details, for example $(selector).mylibrary(options) is not a good choice, so that they can be phased out. Try your best to create components everyone may use, then create backbone-<name> based on that code when possible, otherwise the community will remain fragmented.

AJAX

Routing

CQRS DDD Domain

Huskies

  • huskies/huskies – method or function processor before execution
  • huskies/lock - Lock method according to options, is huskies framework's middle
  • huskies/strict - strict method ,convert and validate arguments, is huskies middleware.

Access Control

Data Modelling

Data Structures

Browser Storage

Dependency Injection

UI Elements

DOM Interaction

Conversion Utilities

Control Flow

Async utilities

Function Utilities

Date Utilities

Array Utilities

String Utilities

Number Utilities

Object Utilities

Math Utilities

Database Utilities

Debugging Utilities

Performance Utilities

WebGL

Canvas

SVG

Shims

Testing

Styling

Templating

Audio

Video

Feature Detection

Other

Crypto

MVC

Backbone

Ember

Foundation

SUIT

  • suitcss/suit – HTML/CSS framework for creating loosely coupled UI components
  • suitcss/base – SUIT base styles for web apps

Utilities

Components

Gaming

CSS Animations

Fonts

Colors

Themes

Aurora

Nightrider

Celtic

Darktone

Display component themes

AngularJS

Localization

Web APIs

반응형
반응형

PuzzleScript: An open-source HTML5 game engine

puzzlescript

 

반응형
반응형

HTML5 File Uploads with jQuery

 

http://tutorialzine.com/2011/09/html5-file-upload-jquery-php/

 

 

Demo    Download

 

What are HTML5 File Uploads?

Uploading files using HTML5 is actually a combination of three technologies – the new File Reader API, the also new Drag & Drop API, and the good ol’ AJAX (with the addition of binary data transfer). Here is a description of a HTML5 file upload process:

  1. The user drops one or more files from their file system to the browser window by dragging. Browsers that support the Drag & Drop API will fire an event, which alongside other useful information, contains a list of files that were dropped;
  2. Using the File Reader API, we read the files in the list as binary data, and store them in memory;
  3. We use the new sendAsBinary method of the XMLHttpRequest object, and send the file data to the server.

Sounds complicated? Yes, it could use some optimization. Fortunately, there are jQuery plugins that can do this for us. One of them is Filedrop, which is a wrapper around this functionality, and provides features for limiting maximum file size and specifying callback functions, which is really handy for integrating it into your web applications.

Currently file uploads work only in Firefox and Chrome, but upcoming major versions of the other browsers also include support for it. A simple fallback solution for older browsers would be to display a regular file input dialog, but we won’t be doing this today, as we will be focusing our attention on using HTML5.

So lets get started!

반응형
반응형

A framework for creating ambitious web applications

 

http://emberjs.com/

 

http://emberjs.com/guides/

 

Building an Ember.js Application

 

Welcome to the Ember.js guides! This documentation will take you from total beginner to Ember expert. It is designed to start from the basics, and slowly increase to more sophisticated concepts until you know everything there is to know about building awesome web applications.

To help you get started, we've also made a 30-minute screencast that will guide you through building a full-featured Ember.js application:

 

Source code for the app we build in the video is available at https://github.com/tildeio/bloggr-client

Most of these guides are designed to help you start building apps right away. If you'd like to know more about the thinking behind Ember.js, you'll find what you're looking for in the Understanding Ember.jssection.

These guides are written in Markdown and are available on GitHub, inside the source/guidesdirectory. If there is something missing, or you find a typo or mistake, please help us by filing an issue or submitting a pull request. Thanks!

We're excited for all of the great apps you're going to build with Ember.js. To get started, select a topic from the left. They are presented in the order that we think will be most useful to you as you're learning Ember.js, but you can also jump to whatever seems most interesting.

Good luck!

 

 

 

 

반응형
반응형

Brunch: Build elegant, simple HTML5 apps

brunch

 

반응형
반응형

Best Of Both Worlds: Mixing HTML5 And Native Code

 

Much has been written recently in the ongoing debate between native and HTML5 applications. There are three principal ways to develop a mobile solution:

  • native code,
  • hybrid mobile app,
  • mobile Web app.

Developing an application in HTML5 is a way to leverage code across multiple platforms, rather than having to write the entire application from scratch for each platform. As such, much of the user interface, perhaps the entire interface, would be done in HTML.

“Hybrid application” is a term often given to applications that are developed largely in HTML5 for the user interface and that rely on native code to access device-specific features that are not readily available to Web applications. Much of this native code is non-visual in nature, simply passing data back to the HTML5 layer of the app, where it is rendered to the user. Libraries such as PhoneGap provide this capability.

html5-native-arrows_500_mini

Much of the debate is not about whether HTML5 is up to the task of powering a mobile application’s user experience. Mark Zuckerberg’s comments about some of the difficulties Facebook has encountered with HTML5 on mobile are well known. Some of Facebook’s issues could likely be addressed through the techniques outlined by Sencha in its Fastbook application and by LinkedIn in its infinite scrolling post. Despite the latter article, LinkedIn subsequently switched directions towards using more native code.

Why Not Mix It Up?

Rather than build an app entirely with native or HTML5 technology, why not mix and match the technologies? With a hybrid application, building a mobile experience that leverages both native and HTML5 code for the user interface is quite possible. This enables the developer to use the most appropriate tool for the job when developing the user interface.

Clearly, developing portions of the user experience in two or more different technologies has some downsides. Chiefly, you would need developers who can handle both native development and HTML5. The portion of the user interface in native code couldn’t be readily used on other platforms and would need to be redeveloped. Given the broader scope of knowledge required by this technique and the difficulties outlined above, why would anyone want to embark on an endeavor that mixes user-interface technologies?

HTML For Rich Document Layout

Perhaps your user experience dictates that documents be displayed in the application with rich formatting. While text formatting can be accomplished on platforms like iOS with NSAttributedString, this document structure is not readily portable to other device platforms, nor does it provide the full complement of features found in HTML. If the document requires formatted content such as tables to be displayed, then a solution like NSAttributedString won’t be up to the task.

Consider the iPad application below, which was developed for a genetic sequencing company. Here we have an example of a hybrid UI:

voyager-screenshot_500_mini
(See larger view.)

Just looking at this application, it’s not readily apparent what has been done in native code and what portions are HTML5. Users of the application would be hard pressed to tell the difference. The document along the right side is of variable length. The table contains expandable rows, complete with CSS3 animations, and other text sections in the document vary in height as well.

Documents such as this are what HTML does best. Trying to create something like this in native code would have entailed considerably greater effort, with little benefit to the user. In this application, the HTML5 is generated with a mustache template, via the GRMustache library for iOS.

voyager-screenshot-shaded_500_mini
The illustration above shows the technologies used to draw each portion of the screen. (See larger view.)

Note that as the user scrolls up, the native document header near the top on the right dynamically resizes to show more content, thus illustrating how portions of the user interface can interact with each other. The user can tap on links and buttons in the HTML document area to pop up an internal Web viewer to load related documents. As we’ll see later in this article, creating this linkage between native and HTML experiences is relatively easy.

Desire For A “Best Of Breed” Approach

As we’ve seen, a given screen may readily mix the two technologies to provide a seamless experience. You may wish to use a native UINavigationController, with its associated UINavigationBar, on iOS, or use the action bar in an Android application. The remainder of the screen may be rendered in HTML5.

Below is an application that uses HTML5 for its shopping-cart experience, but retains the native navigation controller and tab bar for moving between pages of the workflow:

gallery-prints-1_500_mini
(See larger view.)

gallery-review-order_500_mini
(See larger view.)

Here, the HTML5 content is actually loaded from a server, and it controls the workflow throughout the experience. A defined API allows the server-supplied HTML content to modify the contents of the navigation controller bar to suit the page in the workflow.

You may find that native controls, such as MapKit on iOS, provide superior performance to what can be achieved in HTML5. In this case, your HTML5 code could communicate with the iOS native layer and ask it to present the native content over or adjacent to the HTML content.

gallery-map-pin_500_mini
(See larger view.)

gallery-loc-selected_500_mini
(See larger view.)

The examples above illustrate a native store-locator experience, displayed over top of the HTML5 workflow. Upon the user selecting a store location, the data would populate the HTML5 content, and the user would continue their workflow.

Once the user has completed interacting with the map, the results of their interaction may be passed back to the HTML5 document for further handling. Depending on how you wish to structure the application, native “widgets” may be implemented for each platform (iOS, Android, Windows, etc.) and then invoked from the common core HTML5 application. In this strategy, the HTML5 code would provide the workflow for the application, and the native content would sit in the background, waiting to provide the supplementary experience when needed.

If done properly, the user would have little indication of which portions are done in native code and which in HTML.

Ease Of App Updates

Most people are aware that in order to update the native code on an iOS or Android app, it is necessary to resubmit the application through the normal publishing channels for that platform. In the case of iOS, it can take as long as seven days to get app updates approved by Apple. This makes it more difficult to time app updates to marketing requirements and to rapidly respond to changing business needs. Exposing a portion of the user experience through HTML and JavaScript means that some of the experience can be served from the Web and thus be dynamic.

As we saw earlier, it’s possible for this Web-served content to invoke native code in your application via a “bridge” that you create. This is much the same as the bridging mechanism that allows HTML code to communicate with native code in PhoneGap via the PhoneGap plugin interface. The example application shown earlier uses this technique. This approach was chosen chiefly so that the purchasing workflow could be altered without having to redeploy the native application. A page served from the Web may now seamlessly display a natively rendered map using whatever mapping capability is present on the device. A well-defined interface between your Web page and the surrounding native container makes this possible.

Watch That Content!

For content coming from the Web, it’s generally best to restrict the traffic that can flow over this bridge. The built-in functionality of something like PhoneGap provides access to a wide range of device information, some of which may be well beyond your application’s purpose. If that Web content is compromised for some reason, through something like cross-site scripting, you might suddenly find this content invoking native code in a manner you never intended.

For this reason, when bridging from Web-sourced content to native code, use your own bridge code in order to tightly control exactly what the dynamically loaded content may invoke. Some platforms have additional controls to limit what native code may be invoked from a Web view. On Android, classes must explicitly register themselves as being JavaScript-accessible. On Android 4.2, this can be further restricted to the individual methods by adding an @JavaScriptInterface annotation on the methods that you wish to access from a Web view.

Things to consider

  • Pulling content directly from a Web server is fine if the user is online. Remember that these are mobile applications with the potential for connectivity issues. What happens if network connectivity is interrupted? Some offline capability could be retained through the use of AppCache 5, but this needs to be planned for. Another approach will be covered in an upcoming section where updates to the HTML content are stored locally.
  • Hosting content on a Web server requires some infrastructure. There are now more “components” that must be considered as part of your complete app solution. It’s no longer just some native code that’s been deployed via the AppStore and potentially a set of backend services. Care must be taken that site updates do not conflict with the existing interface in the mobile applications. Keep in mind that if site changes necessitate an update to the mobile app itself, not everyone will necessarily update their copy of your app quickly, if at all. For this reason it may become necessary to version the site content so that it may be consumed with older versions of your mobile app. This is very much like the versioning built into some REST 6 based interfaces in order to support compatibility with older client applications.

  • Apple takes a dim view of applications that are merely a Web view wrapped in a native app. Submissions to the iOS AppStore will likely not be approved if you’ve done nothing more than wrap some Web content in a native app. Apple expects your application will make use of some device features that cannot be otherwise accomplished in Mobile Safari. Consider if your application can benefit by integrating with the camera, contact list, local data storage, offline operation, etc. Also remember that the content served in these Web views needs to remain consistent with the original submitted intent of the application.

    If you create a word-search game and then suddenly start serving totally unrelated content in your webviews this will violate Apple’s terms and the app could be pulled from the AppStore. In accordance with the iOS developer agreement, updates may not change the primary purpose of the application by significantly altering the features or functionality of the application as submitted to the App Store.

Pushing Updates To Your App Experience

A variation on the loading of Web content as outlined above is to refresh local content with updates from the Web. In this approach, the Web content (HTML, CSS and JavaScript) is bundled on the server and downloaded to the mobile app client whenever the content is updated. This updated code can now change the user interface, application flow and so on, without the developer needing to update the app via the iOS App Store or Google Play.

Note that you can only update the HTML, CSS and JavaScript in this manner; native code cannot be updated. Apple allows JavaScript code to be downloaded and executed as long as it runs within the context of the UIWebView control in your iOS application. This is the only situation in which code “downloading” is allowed in iOS.

amway-android_500_mini
(See larger view.)

The application above is running on Android. The HTML content has been downloaded to the client as a bundle of content and is now being served locally. Note the use of the action bar to provide a navigation experience that is familiar to Android users. Below is the same application running on iOS, where a UINavigationController is used:

amway-ios_500_mini
(See larger view.)

In addition to speeding up the updating process, this manner of transmitting app changes ensures that users will be running the latest code. In the traditional approach, native app updates are distributed via an application store, and the user is informed that an update is available, although they are not required to install the latest update. Not everyone updates apps regularly. Updating local HTML, CSS and JavaScript via a dynamically deployed update bundle mitigates this issue.

The ability to dynamically update local content is actually part of a commercial hybrid mobile-development platform called Trigger.IO. The Trigger.IO Reload feature permits you to push updates to the HTML portion of your application. Note that native code cannot be updated in this manner. However, if much of your application’s flow is controlled with JavaScript and augmented with native code, then making substantial changes to your application’s workflow dynamically is possible.

Keep in mind that, according to the iOS developer agreement, these updates may not change the primary purpose of the application by significantly altering the features or functionality of the application as submitted to the App Store. As such, major releases would likely still have to be carried out in the traditional manner.

Dynamically Reloading Content For Development And Testing

The ability to dynamically load updates to an app could also accelerate the development process. The native development process on both iOS and Android generally requires application code to be compiled on a desktop computer and then transferred to the device for testing. Some development programs, such as Icenium, with its LiveSync and Ion tools, compile app updates in a cloud environment and then simply download the update to a native app that is already running on your device.

icenium-ion_500_mini
Icenium Ion is reloading updated content. (See larger view.)

As code changes are made and saved on the server, a simple three-finger tap-and-hold gesture will update the app on an iOS device. Icenium makes a similar capability available for Android. Adobe’s PhoneGap Build makes updates possible via a feature known as Hydration. In this case, a developer can instantly reload any changes they make in their IDE onto a variety of devices without having to physically connect the devices to a development machine and then push the code onto the devices.

Each time the application is started with Hydration enabled, the application will check the PhoneGap Build server to see whether a new version is available. If so, the user is prompted to update to the new version. This can make quality assurance of your application easier as well. You won’t have to worry about signing code updates, provisioning and so on if the person testing your app already has the native “shell” application installed.

Be Careful

While the appeal of dynamic application updates is strong, keep in mind that for content sourced from the Web, you must implement some controls to ensure that downloaded code cannot simply call any native method in your app. Failing to do so could expose your user’s data to a third party and violate your agreement with Apple or Google. In addition, updates loaded dynamically must not significantly change the purpose or functionality of the app. Failing to adhere to this would likely result in your application being removed from the iOS App Store or Google Play. Treat these techniques as a way to enhance the user experience and to deliver bug fixes and incremental features quickly, not to thwart the App Store’s approval process.

A Bridge Between Two Worlds

Both iOS and Android offer a Web view control that you can place in a native application. In the section below, I’ll offer some code examples to illustrate how JavaScript in a Web view can communicate with native code and how native code can invoke methods on the JavaScript in the Web view.

phonegap-logo_500_mini
(See larger view.)

Before we look at code, keep in mind that you also have the option to use PhoneGap (Apache Cordova) within an existing application with native controls. Starting with PhoneGap 1.4 for iOS and PhoneGap 1.9 for Android, placing a CordovaWebView into a native ViewController on iOS or into an activity on Android is possible. This permits your Web code to access the entire PhoneGap API and to access any PhoneGap plugins. You could, of course, follow the PhoneGap plugin API to expose your own native code to the CordovaWebView.

Assuming you don’t need the full capabilities of PhoneGap and you simply need to expose a small portion of functionality between the two worlds, implementing your own bridge with a relatively small amount of code is possible. The three applications referenced earlier in this document were all built in this manner using a “private API.” This further ensures that you tightly control the API that governs which portions of native functionality may be accessed by the Web view.

Bridging From iOS To A UIWebView

The UIWebView in iOS and its associated UIWebViewDelegate provide the mechanism that allows native code and JavaScript to communicate with each other. I have prepared a simple iOS application to show how a form in a UIWebView can communicate with a form in native code:

ios-bridge-example_500_mini
(See larger view.)

Note that the upper portion of this screen, with the light-gray background, is rendered by the UIWebView. The lower portion, with the white background, is rendered natively.

This application simply passes a JSON object from the Web view to native code, and vice versa. The code for this and an Android version are available in a GitHub repository.

Invoking Native iOS Code From JavaScript

My standard technique for moving data from the JavaScript to native code is to invoke a native execution method with a command name and pass along data in the form of a JSON string containing the arguments associated with the command.

var nativeBridge = {
   invoke: function (commandName, args) {
      console.log(commandName + ": " + JSON.stringify(args, null, 2));
      window.location = 'js-call:' + commandName + ':' +
                      encodeURIComponent(JSON.stringify(args));
  }
};

This code attempts to navigate the browser to a new URL, but not one with a normal http:// or file:// URL scheme. In this case, we are using a custom protocol scheme of js-call:. On the Objective-C side of things, we’ll trap this attempt to navigate in our UIWebViewDelegate:

(BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType (UIWebViewNavigationType)navigationType

Inside the delegate for this call, we can interrogate the incoming URL to see whether it’s a call from our JavaScript:

NSString *requestURLString = [[request URL] absoluteString];
    if ([requestURLString hasPrefix:@"js-call:"]) {

Now we can pull apart the request to determine the command name and the JSON arguments string:

NSArray *components = [requestURLString componentsSeparatedByString:@":"];
NSString *commandName = (NSString*)[components objectAtIndex:1];
NSString *argsAsString = [ (NSString*)[components objectAtIndex:2] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding ];

Now that we have the arguments as a string, we can turn them into an NSDictionary object:

NSError *error = nil;
NSData *argsData = [argsAsString dataUsingEncoding:NSUTF8StringEncoding];
NSDictionary *args = (NSDictionary*)[NSJSONSerialization JSONObjectWithData:argsData options:kNilOptions error:&error];

With everything decoded, it’s now simple to invoke the right native method to properly take the data that we’ve received from JavaScript and update the native UI:

if ([commandName isEqualToString:@"updateNames"]) {
   [self updateNativeNameValuesWithFirstName:[args objectForKey:@"fname"]
                                    LastName:[args objectForKey:@"lname"]];
}

When successfully handling a call via the js-call URL scheme, we must remember to return a boolean NO value from our delegate to prevent the Web view from actually trying to visit the desired URL.

Invoking JavaScript From iOS Native Code

This approach is a bit more straightforward because we don’t have to use a delegate method. We can simply call the desired JavaScript function by passing the appropriate JavaScript method’s name and required arguments as a string value to the UIWebView’s stringByEvaluatingJavaScriptFromString method.

Here, we take some values from the native view and turn them into a JSON object via an NSDictionary:

NSDictionary *namesDict = @{@"fname": self.fNameTextField.text, 
                            @"lname": self.lNameTextField.text};
NSError *error;
NSData *namesData = [NSJSONSerialization dataWithJSONObject:namesDict 
                                                    options:0 
                                                      error:&error];
NSString *namesJSON = [ [NSString alloc] initWithData:namesData
                                             encoding:NSUTF8StringEncoding] ;

Now that we have the JSON values as a string, we can simply format a command and volley it over the wall to the Web view for execution:

NSString *jsCommand = [NSString stringWithFormat:@"setNames(%@)", namesJSON];
[self.webView stringByEvaluatingJavaScriptFromString:jsCommand];

As simple as that, we’ve roundtripped between JavaScript and Objective-C. This basic technique could, of course, be leveraged to build more complex interactions.

Bridging From Android To A Web View

Below is a screenshot of the Android application running the same HTML and JavaScript code that we used in the native iOS example.

android-bridge-example_500_mini
(See larger view.)

As with the iOS example, the upper portion of this screen, with the light-gray background, is rendered by the Web view. The lower portion, with the white background, is rendered natively. The appearances of the iOS example and the Android example differ because we are using the default component styles for each platform. In addition, the Android example contains an action bar, which Android users would expect to find in an application.

Invoking Native Android Code From JavaScript

Android Web views have the benefit of being able to expose an entire Java class to JavaScript. There’s no need to trap an attempt to navigate off a Web view via some sort of custom URL scheme, as we did with iOS. First, we must signal to the Android Web view that it’s OK for JavaScript to execute on the Web view. I do this when loading the Web view content:

@Override
public void onStart() {
   super.onStart();
   WebSettings webSettings = webview.getSettings();
   webSettings.setJavaScriptEnabled(true);
   webview.loadUrl("file:///android_asset/webviewContent.html");
   webview.addJavaScriptInterface(new WebViewInterface(this), "Android");
}

Note the last line in the code above. We are registering a particular class, in this case WebViewInterface, to be accessed via JavaScript. In addition, this class is being namespaced by the string Android. Thus, in our JavaScript we can test whether the namespace Android is defined and, if so, invoke methods on this class, like so:

if (window.Android) {
   Android.updateNames(JSON.stringify(nameData));
}

On the Java side, the WebViewInterface is a standard Java class. If you are targeting the Android 4.2 SDK, then all methods to be exposed to JavaScript must be decorated with the @JavaScriptInterface attribute:

public class WebViewInterface {
   Context mContext;

   /** Instantiate the interface and set the context */
   WebViewInterface(Context c) {
       mContext = c;
   }

   @JavaScriptInterface
   public void updateNames(String namesJsonString) {
      Log.d(getPackageName(), "Sent from webview: " + namesJsonString);
      try {
         JSONObject namesJson = new JSONObject(namesJsonString);
         final String firstName = namesJson.getString("fname");
         final String lastName = namesJson.getString("lname");

         // When invoked from JavaScript, this is executed on a thread 
         // other than the UI thread.
         // Because we want to update the native UI controls, we must 
         // create a runnable for the main UI thread.
         runOnUiThread(new Runnable() {
            public void run() {
               fnameEditText.setText(firstName);
               lnameEditText.setText(lastName);
             }
         });
      } catch (JSONException e) {
         Log.e(getPackageName(), 
            "Failed to create JSON object from Web view data");
      }
   }
}

Note that when the methods on this class are invoked by JavaScript, they are not executed on the main UI thread. Thus, if our intention is to update any part of the UI, we must create a new runnable and post it for execution on the main UI thread, like so:

runOnUiThread(new Runnable() {
   public void run() {
      fnameEditText.setText(firstName);
      lnameEditText.setText(lastName);
   }
});

Invoking JavaScript from native Android code is essentially similar to how we call JavaScript from Objective-C. We load the JSON representation of the data into a string and then form a JavaScript function call. One difference is that the function reference must be prefixed with the JavaScript: protocol scheme:

public void sendNamesToWebView() {
   JSONObject namesJson = new JSONObject();
   try {
      namesJson.put("fname", fnameEditText.getText().toString());
      namesJson.put("lname", lnameEditText.getText().toString());
      webview.loadUrl( "JavaScript:setNames(" + namesJson.toString() + ")" );
   } catch (JSONException e) {
      Log.e(getPackageName(), 
        "Failed to create JSON object for Web view");
   }
}

That’s all there is to roundtripping JSON data between JavaScript and native Android code. Both sample applications are available in the GitHub repository for your reference.

Web Views: What’s The Downside?

Like most things in software development, there must be some caveats to developing with Web views. Keep these in mind when considering the hybrid approach and determining which portions of your application to do with which technologies.

  • Not all Web views render the same
    The capability of Web views has improved markedly in the last two years. However, your user base may not be running the latest and greatest version of Android or iOS. The Android platform has generally lagged behind the iOS platform in the capability and performance of its Web view. Google appears to be putting in a renewed effort to improve that situation, but users stuck on old versions of Android (especially releases before Ice Cream Sandwich 4.x) might find that the performance of Web views, especially those with complex layouts, do not match what is achievable on iOS. Developers will need to test the HTML5 code on Android 2.2, 2.3 and 4.x to ensure that content renders consistently. Reserve sufficient time in your project to perform adequate testing across all mobile OS versions that you intend to support.
  • Performance
    Web views are typically not as performant as native code. However, in many situations, you may find the performance to be perfectly acceptable, particularly on current hardware. Keep in mind that bridging calls between the native and Web view portions of your code will exact a performance toll. You won’t want to make calls across this bridge at sub-second intervals, but for most applications this is not an issue.
  • Scrolling behavior
    Users might be able to distinguish between the way Web views scroll and the way native portions of the app scroll. Some of this can be mitigated in new versions of WebKit with the CSS3 -webkit-overflow-scrolling: touch property. You might also wish to look at solutions such as FTScroller 7 and iScroll 8.
  • Complexity
    As mentioned earlier, if you will be serving some content from Web servers you must ensure you have the infrastructure necessary to support this. Because your application now spans native code, Web servers, and potentially backend services there are more points of failure. When making Web content changes you must perform backwards compatibility testing against earlier deployed versions of the application to ensure existing versions of your application still running on users devices will continue to perform as expected.
  • Developer Agreement Compliance
    Familiarize yourself with the restrictions each app marketplace might impose on content provided from the Web. As this article identified there are some notable restrictions, particularly on the iOS platform, on what your app is permitted to do with content sourced from the Web. Failure to take these restrictions into account could result in your app not being approved for release, or an existing app being pulled from the AppStore.
  • Security
    As stated earlier content sourced from the Web should be treated with some suspicion, particularly if it will be interacting with an interface to your native code. Ensure you’ve exposed only those portions of your native code that are truly required for interaction with the Web layer. Failure to do so could result in some consequences should compromised Web content be able to freely into call your native code. Make sure you take standard Web security practices into account to ensure your Web content cannot be compromised to begin with.

Given the flexibility afforded by a hybrid solution, you have the freedom to write portions of your application in native code if you find that the performance of the Web view is insufficient for a given interaction. Of course, the more native code you write, the more code will have to be rewritten for every platform you intend to support. It’s a trade-off; however, a hybrid solution puts you in control of the application’s flexibility and performance.

반응형
반응형

Choosing the right visualization tool for your task

 

http://blog.datamarket.com/2012/04/04/choosing-the-right-visualization-tool-for-your-task/

 

 

@ Chart Sites

https://developers.google.com/chart/?hl=ko-KR&csw=1

http://raphaeljs.com/

http://mbostock.github.io/protovis/

http://d3js.org/

https://github.com/mbostock/d3

https://github.com/mbostock/d3/wiki/Gallery

http://www.tableausoftware.com/

http://www.tableausoftware.com/learn/gallery

http://www.visualdatatools.com/DataGraph/

http://ggplot2.org/

http://processing.org/

http://www.highcharts.com/

http://www.highcharts.com/demo/

The right tool for the task

Simple one-off charts

The most common tool for simple charting is clearly Excel. It is possible to make near-perfect charts of most chart types using Excel – if you know what you’re doing. Many Excel defaults are sub-optimal, some of the chart types they offer are simply for show and have no practical application. 3D cone shaped “bars” anyone? And Excel makes no attempt at guiding a novice user to the best chart for what she wants to achieve. Here are three alternatives we’ve found useful:

  • Tableau is fast becoming the number one tool for many data visualization professionals. It’s client software (Windows only) that’s available for $999 and gives you a user-friendly way to create well crafted visualizations on top of data that can be imported from all of the most common data file formats. Common charting in Tableau is straight-forward, while some of the more advanced functionality may be less so. Then again, Tableau enables you to create pretty elaborate interactive data applications that can be published online and work on all common browser types, including tablets and mobile handsets. For the non-programmer that sees data visualization as an important part of his job, Tableau is probably the tool for you.
  • DataGraph is a little-known tool that deserves a lot more attention. A very different beast, DataGraph is a Mac-only application ($90 on the AppStore) originally designed to create proper charts for scientific publications, but has become a powerful tool to create a wide variety of charts for any occasion. Nothing we’ve tested comes close to DataGraph when creating crystal-clear, beautiful charts that are also done “right” as far as most of the information visualization literature is concerned. The workflow and interface may take a while to get the grips of, and some of the more advanced functionality may lie hidden even from an avid user for months of usage, but a wide range of samples, aggressive development and an active user community make DataGraph a really interesting solution for professional charting. If you are looking for a tool to create beautiful, yet easy to understand, static charts DataGraph may be your tool of choice. And if your medium is print, DataGraph outshines any other application on the market.
    • The best way to see samples of DataGraph’s capabilities is to download the free trial and browse the samples/templates on the application’s startup screen.
  • R is an open-source programing environment for statistical computing and graphics. A super powerful tool, R takes some programming skills to even get started, but is becoming a standard tool for any self-respecting “data scientist”. An interpreted, command line controlled environment, R does a lot more than graphics as it enables all sorts of crunching and statistical computing, even with enormous data sets. In fact we’d say that the graphics are indeed a little bit of a weak spot of R. Not to complain about the data presentation from the information visualization standpoint, most of the charts that R creates would not be considered refined and therefore needs polishing in other software such as Adobe Illustrator to be ready for publication. Not to be missed if working with R is the ggplot2 package that helps overcome some of the thornier of making charts and graphs for R look proper. If you can program, and need a powerful tool to do graphical analysis, R is your tool, but be prepared to spend significant time to make your outcome look good enough for publication, either in R or by exporting the graphics to another piece of software for touch-up.
    • The R Graphical Manual holds an enormous collection of browsable samples of graphics created using R – and the code and data used to make a lot of them.

Videos and custom high-resolution graphics

If you are creating data visualization videos or high-resolution data graphics, Processing is your tool. Processing is an open source integrated development environment (IDE) that uses a simplified version of Java as its programming language and is especially geared towards developing visual applications.

Processing is great for rapid development of custom data visualization applications that can either be run directly from the IDE, compiled into stand-alone applications or published as Java Applets for publishing on the web.

Java Applets are less than optimal for web publication (ok, they simply suck for a variety of reasons), but a complementary open-source project – Processing.js – has ported Processing to JavaScript using the canvas element for rendering the visuals (canvas is a way to render and control bitmap rendering in modern web browsers using JavaScript). This is a far superior way to take processing work online, and strongly recommended in favor to the Applet.

The area where we have found that Processing really shines as a data visualization tool, is in creating videos. It comes with a video class called MovieMaker that allows you to compose videos programmatically, frame-by-frame. Each frame may well require some serious crunching and take a long time to calculate before it is appended to a growing video file. The results can be quite stunning. Many of the best known data visualization videos are made using this method, including:

Many other great examples showing the power of Processing – and for a lot more than just videos – can be found in Processing.org’s Exhibition Archives.

As can be seen from these examples Processing is obviously also great for rendering static, high-resolution bitmap visualizations.

So if data driven videos, or high-resolution graphics are your thing, and you’re not afraid of programming, we recommend Processing.

Charts for the Web

There are plenty – dozens, if not hundreds – of programming libraries that allow you to add charts to your web sites. Frankly, most of them are sh*t. Some of the more flashy ones use Flash or even Silverlight for their graphics, and there are strong reasons for not depending on browser plugins for delivering your graphics.

We believe we have tested most of the libraries out there, and there are only two we feel comfortable recommending, each has its pros and cons depending on what you are looking for:

  • Highcharts is a JavaScript charting library that renders vector based, interactive charts in SVG (or VML for older versions of Internet Explorer). It is free for non-commercial use, and commercial licenses start at $80. It is a flexible and well designed library that includes all the most common chart types with plenty of customization and interactivity options. Interestingly enough even though Highcharts is a commercial solution, the source code is available to developers that want to make their own modifications or additions. With plenty of examples, good documentation and active user forums, Highcharts is a great choice for most development projects that need charting.
  • gRaphaël is another JavaScript charting library built on top of Raphaël (see below). Like HighCharts, gRaphaël renders SVG graphics on modern browsers, falling back to VML for IE <9. While holding a lot of promise, gRaphaël is not a very mature library and with limited capabilities, few chart types, even fewer examples and pretty much non-existent documentation. It is however available under proper open source licenses and could serve as a base for great things for those that want to extend these humble beginnings.

Other libraries and solutions that may be worth checking out are the popular commercial solution amCharts, Google’s hosted Chart Tools and jQuery library Flot.

Special Requirements and Custom Visualizations

If you want full control of the look, feel and interactivity of your charts, or if you want to create a custom data visualization for the web from scratch, the out-of-the box libraries mentioned above will not suffice.

In fact – you’ll be surprised how soon you run into limitations that will force you to compromise on your design. Seemingly simple preferences such as “I don’t want drop shadows on the lines in my line chart”, or “I want to control what happens when a user clicks the X-axis” and you may already be stretching it with your chosen library. But consider yourself warned: The compromises may well be worth it. You may not have the time and resources to spend diving deeper, let alone writing yet-another-charting-tool™

However, if you are not one to compromise on your standards, or if you want to take it up a notch and follow the lead of some of the wonderful and engaging data journalism happening at the likes of the NY Times and The Guardian, you’re looking for something that a charting library is simply not designed to do.

The tool for you will probably be one of the following:

  • Raphaël, gRaphaël’s (see above) big brother. Raphaël is a powerful JavaScript library to work with vector graphics. It renders SVG graphics for modern browsers and falls back to VML for Internet Explorer 6, 7 and 8. It comes with a range of good looking samples and decent documentation. Raphaël is open source, and any developer should be able to hit the ground running with it to develop nice looking things quite fast. We don’t recommend Raphaël for the advanced charting part, but for entirely custom data visualizations or small data apps it may very well be the right tool for the task.
  • Protovis is an open source JavaScript visualization toolkit. Rather than simply controlling at a low level the lines and areas that are to be drawn, Protovis allows the developer to specify how data should be encoded in marks – such as bars, dots and lines – to represent it. This approach allows inheritance and scales that enable a developer to construct custom charts types and layouts that can easily take in new data without the need to write any additional code. Protovis natively uses SVG to render graphics, but a couple of efforts have been made to enable VML rendering making Protovis an option for older versions of Internet Explorer that still account for a significant proportion of traffic on the web.

    Protovis is originally written by Mike Bostock (now data scientist at Square) and Jeffrey Heer of the Stanford Visualization Group. Their architectural approach is ingenious, but it also takes a bit of an effort to wrap your head around, so be prepared for somewhat of a learning curve. Luckily there are plenty of complete and well-written examples and decent documentation. Once you get going, you will be amazed at the flexibility and power that the Protovis approach provides.

  • D3.js or “D3″ for short is in many ways the successor of Protovis. In fact Protovis is no longer under active development by the original team due to the fact that its primary developer – Mike Bostock – is now working on D3 instead.

    D3 builds on many of the concepts of Protovis. The main difference is that instead of having an intermediate representation that separates the rendering of the SVG (or HTML) from the programming interface, D3 binds the data directly to the DOM representation. If you don’t understand what that means – don’t worry, you don’t have to. But it has a couple of consequences that may or may not make D3 more attractive for your needs.

    The first one is that it – almost without exception – makes rendering faster and thereby animations and smooth transitions from one state to another more feasible. The second is that it will only work on browsers that support SVG so that you will be leaving Internet Explorer 7 and 8 users behind – and due to the deep DOM integration, enabling VML rendering for D3 is a far bigger task than for Protovis – and one that nobody has embarked on yet.

반응형
반응형

Video in Web Design

http://webdesign.tutsplus.com/articles/design-theory/video-in-web-design/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+webdesigntutsplus+%28Webdesigntuts%2B%29 

 

http://www.realmacsoftware.com/clear/

http://www.fiftythree.com/paper

http://www.handheldconf.com/

http://playgroundinc.com/

http://symbolset.com/

http://www.spotify.com/

http://www.slowmo.co.uk/

http://daneden.me/

 

 

Video itself has been around for a long time; in films, on the television and now readily available to play on our phones, tablets and other devices. Video on the web has also been around for a long time. We started out with heavy-weight flash files of videos and animations, whereas now we have HTML5 video and so many more options for including video in our web pages. Heck, half the time it’s even just as easy as dropping some embed code into a website. In short, we’ve never had it as easy when it comes to using video on the web.


The Evolution of Video

Designing with video was much harder in the past than it is now. Taking good quality video footage often involved heavy and expensive equipment and software, whereas now we can use our normal digital cameras (or even our phones!) to take great quality footage. And if you wanted animated sequences on your website, you had to either be very good at illustrating digitally, know a lot of Actionscript, or your way around Flash, or hire someone else to do it. Now, there are tools and pieces of software out there that help you to create animations all by themselves.

Also, think about the creation of YouTube. Founded in 2005, YouTube is the most popular service that people use to upload and share their own videos. Even massive corporations and businesses use it to share popular clips or news from their TV shows.

In my opinion, YouTube brought around a bit of an evolution of video on the web. They made it easy for viral campaigns to spread quickly and video quickly exploded onto the scene. YouTube offered something that few had been able to do before: anybody and everybody could create video and share it to whomever they liked, regardless of their experience or technical ability.


Video on the Web Today

Nowadays, we have so many technologies at our disposal that Flash has mostly fallen by the wayside. HTML5 makes it much easier for us to develop ways to display our videos and other animated, visual footage in our websites. Having this technology is great, as it means that we have much better opportunities to use video in our designs and actually use it to make our users’ experiences better.

But I’m not here to talk about YouTube and Vimeo all day, or even to tell you about all the technical advances and techniques you can use to include video in your websites. Instead, I’ll walk you through why it’s good to include videos in your design and what makes video great.


How We Can Use Video

Video can be used in so many ways to enhance our designs and make the user journey and experience better. Just like you would with various imagery (whether it’s photography, icons or animations) you should be aiming to use video in your designs to improve your designs. Keep in mind you want your message to be clear with or without the videos.

With any video it’s important that you think clearly about the message you want to project. While this can depend totally on the brand, product or service, use video as carefully as you would any other elements in your design.

That said, we can use videos…

..To Introduce

Videos are great for introducing your users to a product or service without overpowering them with a list of features a mile long. Think of many SaaS websites; how many can you see with an intro video that explains the product or service a little more?

The key with this video is to make it the focus of your design. While you will want to mention the features in text and imagery below, having a video that shows the main features in a creative way is a sure-fire way of getting your users to notice the product and want to try it more.

A couple of great examples of this are on the Clear app and Paper app websites.

Clear

Clear is a to-do and list-tackling app. Clear’s website is a great example of using video as a focus, but also ensuring that the message about the app comes through loud-and-clear without the video.

clear-1

The video is placed in the header of the website, right next to the app download links, and when clicked it loads the video in a little overlay.

This video is just an introduction to the product and app itself, but what works well is the consistency in the brand and visuals from the website design to the video. As you’ll have learned in previous articles, consistency is key to creating a strong brand message and in matching those together so well, it will make users more likely to trust the brand and therefore go on to buy the app.

clear-2

Paper

Paper is an app that allows you to sketch and draw beautifully on your iPad.

The focus on the video on the Paper website is even bigger than on the Clear website, with a larger, really visually-striking header image in place, with a video play icon over the top of the image. On clicking to play the video, though, it also opened in an overlay on top of the rest of the website design.

paper-1

Again, as with Clear, the brand message, style and tone of voice is kept very similar to the rest of the website design. Creating consistency like this can only help you to gain more users trust in the long run – so be sure to not create a mismatch in styles if you do decide to include a video in your website designs.

paper-2

..To Delight

One great thing about video (if used cleverly) is that you can use it to delight your users, by introducing hidden features that they might not have thought about. Almost like a little easter egg, but a little more visible, and much more visual!

This use of video in designs is purely subjective and would again depend on how the brand needs to be represented. This might not be suitable in website designs that are for professional companies, but would be perfect in something a little more casual in style.

A couple of websites using this to great effect are Handheld Conf and Playground Inc.

Handheld Conf

Handheld Conf is a conference that describes itself as “big ideas for small devices”. On the homepage of the Handheld Conf website, there’s a line up of amazing speakers and their topics, along with a photo. Now, when you hover over the speaker photos, they come to life!

handheldconf

This is an amazing little treat for users; almost uncannily like photographs in the world of Harry Potter, that move. As soon as your cursor hovers away from the photos, they pause at the point where your cursor left the photo. And if you go back on to them, they resume.

 

Using video like this is a great way to add a little more interactivity into your websites, but also creating small ways for your user to enjoy browsing the website more.

Playground Inc

Playground Inc are a creative digital agency based in Toronto. On their homepage, they use animation brilliantly to help illustrate their ideas and beliefs. These animations only activate once you’ve scrolled to that part of the page and before that, they look like static illustrations.

playgroundinc

This is a great way to add interest to your website that will delight users, as it is something that is totally unexpected but that enhances the way they can interact with your site.

..To Add Interest

Hand in hand with using video to delight your users, you can also use video to add extra visual interest and weight to your design elements. This is a great way to use video as it ensures that you can keep the interest level in your website higher than if you had much fewer visual elements to catch the user’s eye.

A great example of this is seen on the Symbolset website.

Symbolset

Symbolset create icon web fonts for all of us lovely web people to use. Personally I think the way that Symbolset works is pretty inventive and the way they use video on their website is no different.

symbolset

If you’re using the Symbolset fonts on the Desktop (in Photoshop, for example) then you can type out the keyword for the icon you require and it will appear for you. In the same manner, they have used this in their video.

Symbolset also really cleverly make use of colour alongside each of the messages they type out to you in their video, keeping visual interest at a massive high. This sort of video is also really inclusive, as it makes it feel like the website is talking to you and connecting personally with you; which again will help to build the trust between the user and the company itself.

..To Replace Large Background Images

A trend that has long been around is the large, often (though not restricted to) full-screen-sized background image. Some companies are now instead using this as an opportunity as a space to place their full-screen-size video.

While this is nothing new, you have to think carefully about how you use this style of video in your designs. Instead of just a large full-scale background image – which is relatively easy to work around with your design elements – a video is something that is always moving and may cause havoc with your design elements (think typography, colour, buttons, other elements like that) when mixed with the moving video. It’s a new challenge, but can be used cleverly with careful thought.

A couple of great examples of large background videos are by Spotify and Slow Mo.

Spotify

Spotify are a popular music-streaming service. Their website homepage utilises the large-scale background video to great effect, with a looping video with a minimal amount of other design elements laid over the top.

spotify

Spotify have also decided to include audio on this video (which you can turn off very easily, a must have when including audio on any website), which enhances the video even further.

The video, audio and design of the homepage overall helps to set the tone for the service and helps the users understand a little more about the service and their tagline of “music for every moment”, all without directly saying what Spotify actually does.

Slow Mo

Slow Mo are high speed camera specialists. They use video in place of an image for the hero area at the top of the homepage. What’s clever about Slow Mo is that at their essence they are a company that sells high speed cameras, and they use video to help sell that.

slowmo

The videos they use on their homepage are all played automatically in a slow-motion style and tie in perfectly with the brand’s name. It also creates a lot of visual interest, while the contrast between the video and the text that overlays it is always kept strong.

..To Improve Your Storytelling

One final thing that you can do by using video in your designs is to use it to improve your storytelling skills. Storytelling isn’t anything new, but you can use video to enhance it even more. Storytelling should be at the heart of your designs and video is one step to take that can help improve the experience that your users will have on your website.

A great example of this in action is on Dan Eden’s personal website.

Daneden.me

Dan is a designer, who has recently been hired by Dropbox as the first Dropbox Design Intern. In the portfolio section of Dan’s website, alongside the project title and descriptions he also has (beautiful looking) videos that walk the user through the project.

daneden

This is brilliant. Instead of showing simple screenshots or linking to the website, Dan is improving the experience of his users by allowing them to see the project in action without going anywhere else. This is great as it adds interest to the page, but it will also encourage users to visit a website if they like the look of it.

It can sometimes be very hard to get an inkling for how a website works without browsing it yourself, but Dan has managed to cross that bridge without adding any extra steps for his users.

 

반응형

+ Recent posts