You searched for: 'native'

Thursday, April 22nd, 2010

Desktop Notifications with Webkit

Category: JavaScript, WebKit

Mohit Muthanna has a nice blog post explaining how you can create desktop notifications with the latest Webkit/Chrome.

desktop-notifications

There are essentially three API calls you use:

  • window.webkitNotifications.requestPermission(callback) – Request access to Desktop Notifications for this domain.
  • window.webkitNotifications.checkPermission() – Returns 0 if this domain has Desktop Notification access.
  • window.webkitNotifications.createNotification(icon,title,body) – Returns a popup notification instance, which you can display by calling show() on it.

The demo code is pretty straight forward:

javascript

  1. function Notifier() {}
  2.  
  3. // Request permission for this page to send notifications. If allowed,
  4. // calls function "cb" with "true" as the first argument.
  5. Notifier.prototype.RequestPermission = function(cb) {
  6.   window.webkitNotifications.requestPermission(function() {
  7.     if (cb) { cb(window.webkitNotifications.checkPermission() == 0); }
  8.   });
  9. }
  10.  
  11. // Popup a notification with icon, title, and body. Returns false if
  12. // permission was not granted.
  13. Notifier.prototype.Notify = function(icon, title, body) {
  14.   if (window.webkitNotifications.checkPermission() == 0) {
  15.     var popup = window.webkitNotifications.createNotification(
  16.       icon, title, body);
  17.     popup.show();
  18.     return true;
  19.   }
  20.  
  21.   return false;
  22. }

The user request happens the same way the W3C geo location API requests access – a toolbar popping up asking you if you are OK to see Desktop Notifications. This is good as I can see this being used by people to fake IM messages – much like they do now in the browser.

The notifications animate in from top right and have the originating URL and a “block” link – which makes it hard to use them for phishing.

Interesting concept and if it could use native systems like Growl it would spell the end of awkward alerts and hand-rolled notification windows in the document.

Posted by Chris Heilmann at 5:36 am
3 Comments

++++-
4 rating from 6 votes

Sunday, April 18th, 2010

SproutCore @ JSConf: SeedJS, great features, amazing demos

Category: SproutCore

Mike Ball & Evin Grano of Eloqua gave a fun talk this morning at JSConf, and they had great stuff to show.

SeedJS

seedJS.org

SproutCore is supporting CommonJS, but a lot of code was written by folks before CommonJS….. so they created SeedJS a package management tool that groks CommonJS and packages everything up for you. seed is built on top of git and lets you do things like:


seed fork markdown
seed install js-beautify

Greenhouse

Greenhouse is an interface builder for SproutCore (in the Atlas, Ares, vein). SproutCore was actually written with tooling in mind. For example, the tool can load up your SproutCore app and suppress the main loop, and get access to your custom views.

greenhouse

Touch

SproutCore has added really nice touch support natively into the framework. The guys showed the sample apps running on an iPad. They have done a lot of work here. For example, the physics for bouncing when you scroll, the list picker does the right UI when rotating to portrait mode. In a couple of weeks they took this and got a few apps written, including:

NPR

I love this. A team recreated the NPR iPad application using SproutCore… in a matter of *days*. And it really works. You can read the news, listen to the audio, etc. What is so cool about it is the fact that you can’t tell the difference between the HTML version and the native version. I really want Joe Hewitt to get his hands on this. In fact, on some scrolling tests the HTML version felt *smoother* to me. This is a real feet and a strong vindication for the Web platform. Not only do you get reach, but you can deliver first class applications on mobile and beyond. Fantastic job guys.

npr

Oh, and this stuff works on any touch device. And it is hardware accelerated. You can also check out their new touch based doc tool.

The SproutCore team have a post introducing SproutCore Touch.

Posted by Dion Almaer at 8:28 am
2 Comments

++---
2.5 rating from 2 votes

Friday, April 16th, 2010

“Visualize” data as graphs

Category: Canvas, JavaScript, jQuery

How do you visualize data in interesting ways but allow the data to be accessible for all? The jQuery Visualize work is the latest library that groks HTML and replaces the table with pretty graphs:

The Visualize plugin parses key content elements in a well-structured HTML table, and leverages that native HTML5 canvas drawing ability to transform them into a chart or graph visualization. For example, table row data values serve as chart bars, lines or pie wedges; table headers become value and legend labels; and the title and caption values provide title labels within the image. Visualize also automatically checks for the highest and lowest values in the chart and uses them to calculate x-axis values for line and bar charts. Finally, the plugin includes two different CSS styles — one light and one dark — that can be used as is, or can serve as a starting point to customize chart and graph presentation to match any application style.

jvisualize

Someone pointed out that “accessible” means many things. If you have a 10,000 row table, it may not be easy to consume…. but hey!

Posted by Dion Almaer at 9:17 am
Comment here

++++-
4.5 rating from 17 votes

Wednesday, April 14th, 2010

Google to open source On2 VP8 codec at Google I/O?

Category: Video

There was a big cheer at last years Google I/O when Google Wave was demoed. It made a great demo and really showed that the Web can do a looooot more than we think.

It sounds like we will have another big cheer moment for this years Google I/O though, and it will won’t be for a demo, but for something more meaningful.

It appears that Google will open source VP8, the On2 codec at the event. Video has been painful for the Open Web crew. Many bash Theora on the grounds of quality, and then others hit back saying that it is hog-wash. H.264 has been taken up almost ubiquitously, with Mozilla holding out on principled grounds (which has created a groundswell around that decision too). The folks who make money on H.264 extended our puff on the pipe, but wouldn’t it be nice for the Open Web to have a true open video alternative?

That is what folks like the FSF begged Google for when the On2 acquisition was happening. Now we may have our wish.

This doesn’t mean that all is well. Having a codec is one thing, but getting it out there and implemented is another. Chrome and Mozilla may support it out of the gate, but what about Apple and Microsoft? At the very least though, having a truly viable open codec allows us to hold the H.264 folks feet to the fire.

Google also recently funded open video work on ARM that does use Theora. I am looking forward to IO!

Posted by Dion Almaer at 1:15 am
7 Comments

++++-
4.7 rating from 27 votes

Tuesday, April 13th, 2010

Traits.js: New trait composition library

Category: JavaScript

A few libraries out there have dabbled in the world of traits. JSTraits is the most notable of this area.

Tom Van Cutsem and Mark Miller of Google have a new traits library at traitsjs.org that is defined to work in tandem with the new object-manipulation API defined on Object in ES5.

Traits are an alternative to mixins and enable a “safe” form of multiple inheritance.

traits.js introduces traits without also introducing classes. In this library, traits are like Javascript’s functions: anonymous, first-class and freely lexically nestable.

What about the roles of classes not normally supported by traits, such as instance-private state and constructors to initialize that state? These roles are already supported by Javascript’s functions: you can nest traits inside functions that close over the required state, and you can use the function body as the “constructor”. Here’s an obligatory ‘point-and-color’ example:

javascript

  1. function makeColorTrait(col) {
  2.   return Trait({
  3.     color: function() { return col; }
  4.   });
  5. }
  6. function makePoint(x, y) {
  7.   return Trait.create(      // create an instance of a trait
  8.    Object.prototype,        // that inherits from Object.prototype
  9.    Trait.compose(           // and is the composition of
  10.      makeColorTrait('red'), // a color trait
  11.      Trait({                // and an anonymous point trait
  12.        getX: function() { return x; },
  13.        getY: function() { return y; },
  14.        toString: function() { return ''+x+'@'+y; }              
  15.      })));
  16. }
  17. var p = makePoint(0,2);
  18. p.color() // 'red'

It is also interesting to read the source and see a codebase that both supports ES5 and also is backwards compatible. Hence code such as:

var bindThis = Function.prototype.bind
? function(fun, self) { return Function.prototype.bind.call(fun, self); }
: function(fun, self) {
function funcBound(var_args) {
return fun.apply(self, arguments);
}
return funcBound;
};

var hasOwnProperty = bindThis(call, Object.prototype.hasOwnProperty);
var slice = bindThis(call, Array.prototype.slice);

// feature testing such that traits.js runs on both ES3 and ES5
var forEach = Array.prototype.forEach
? bindThis(call, Array.prototype.forEach)
: function(arr, fun) {
for (var i = 0, len = arr.length; i < len; i++) { fun(arr[i]); } }; var freeze = Object.freeze || function(obj) { return obj; }; var getPrototypeOf = Object.getPrototypeOf || function(obj) { return Object.prototype }; [/javascript] Some of that could make a nice ES5 shim library. (UPDATE: Kris Kowal pointed us to the shim that Narwhal uses. Thanks Kris!)

Posted by Dion Almaer at 1:17 am
3 Comments

++++-
4.3 rating from 11 votes

Monday, April 5th, 2010

Prototype 1.7 RC Sizzles…

Category: JavaScript, Library, Prototype

Andrew Dupont and the the Prototype team have announced the first RC of Prototype 1.7 which changes the selector engine to Sizzle, a new event API, has new layout/dimensions API, and more.

Element#on

Element#on is a new way to access the Prototype event API. It provides first-class support for event delegation and simplifies event handler removal.

E.g.

javascript

  1. $("messages").on("click", function(event) {
  2.   // simple version
  3. });
  4.  
  5. // can also pass in a selector which means
  6. $("messages").on("click", "a.comment_link", function(event, element) {
  7.   // ...
  8. });
  9.  
  10. // instead of
  11. $("messages").observe("click", function(event) {
  12.   var element = event.findElement("a.comment_link");
  13.   if (element) {
  14.     // ...
  15.   }
  16. });

Element.Layout

The second major feature in 1.7 is Element.Layout, a class for pixel-perfect measurement of element dimensions and offsets.

Now you don’t have to decide between properties like offsetWidth (which return numbers, but not the numbers you want) or retrieving computed styles (which have their own set of quirks and require a call to parseInt).

javascript

  1. // Simple case
  2. $('troz').measure('width'); //-> 150
  3. $('troz').measure('border-top'); //-> 5
  4. // Offsets, too:
  5. $('troz').measure('top'); //-> 226
  6.  
  7. // More complex case
  8. var layout = $('troz').getLayout();
  9. layout.get('width');  //-> 150
  10. layout.get('height'); //-> 500
  11.  
  12. layout.get('padding-left');  //-> 10
  13. layout.get('margin-left');   //-> 25
  14. layout.get('border-top');    //-> 5
  15. layout.get('border-bottom'); //-> 5
  16.  
  17. layout.get('padding-box-width'); //-> 170
  18. layout.get('border-box-height'); //-> 510

Other fixes

The JSON interface slated for ECMAScript 5 is already being implemented in major browsers. It uses many of the same method names as Prototype’s existing JSON implementation, but with different behavior, so we rewrote ours to be ES5-compliant and to fall back to the native JSON support where possible. A few other methods, like Object.keys, received similar treatment.

Posted by Dion Almaer at 1:34 pm
8 Comments

++++-
4 rating from 48 votes

Thursday, April 1st, 2010

Are browsers Quake-ing in their boots?

Category: GWT, Showcase

Ben and I are often touting the fact that we are about to see amazing Web applications as browsers support more and more of “HTML5” and the engines under the hood have become world class.

The GWT team has developed something that truly shows off this engine in their port of Quake2 to GWT. Seeing the game run with amazing fps in a browser, with online multiplayer network support via WebSockets, is something to truly behold.

Give it a watch:

And build it and run it yourself!

How did the team create the port?

Stefan Haustein, Ray Cromwell and Joel Webber were at a GWT summit and happened upon Jake2 the Java port of Quake2 that runs on top of JOGL for OpenGL. Ray could see that Joel had a glint in his eye, and the porting began!

To get the rich 3D graphics they went for WebGL using a GWT wrapper library that Stefan had built. Jake2’s heavy use of java.nio.Buffers were handled by implementing JRE classes that mapped those to WebGL typed arrays. File system code that used RandomAccessFile was emulated by using HTML5 LocalStorage. The OpenAL audio system was implemented using HTML5 audio.

The various team members got varying fps depending on their machines. A Linux notebook managed 60fps, a Mac Pro got 45fps, and a Macbook Pro got 25fps. WebKit was able to perform the best of the browsers right now because it doesn’t have the multi-process per tab tax that means a lot of OpenGL buffer copying.

I think this is a big deal in a couple of ways:

  • You can build fantastic games that use rich 3D engines and fast network access right on the Web. How do you “join a game”? You just share a URL! Tweet away! Now you can have these rich games just a URL a way. No install required.
  • Game engines push a platform. Although we are talking about building an older game engine (doubt that the latest and greatest engines would run like this!) this is PLENTY for building rich effects and applications. Take some of this richness and look at something like Google Docs. How much smoother and nicer can it be? We can create beautiful applications with effects like butter right now.

Credit

Ray Cromwell (who posted on this here) contributed audio/mouse/keyboard and localstorage for prefs, plus some minor GL shader debugging. Joel Webber and Stefan Haustein did the other 80% (Joel did the majority of the original code surgery to get the multiplayer game running under GWT minus graphics, Stefan did the heavy lifting on WebGL and singlehandedly ported the single-player game logic)

People still claim that “the browser is slow” and “JavaScript is slow”. Not in 2010 my friends!

Who needs Native Client now when you can build apps and games like this! Well, to be fair, there is a niche of folks who want to use C libraries and frankly prefer that world… so NaCl is for them.

For the rest of us though? Our world keeps getting better, almost daily!

Posted by Dion Almaer at 4:19 pm
19 Comments

++++-
4.9 rating from 49 votes

Wednesday, March 31st, 2010

Chrome Embeds Flash!

Category: Adobe, Flash, Google, Mozilla

flashchrome

For some time now, Adobe has been working with platform vendors to include the Flash plug-in pre-loaded. We’ve seen this ages ago in Windows, and more recently with Adobe’s efforts in the Open Screen Project.

Now, there’s news of something a little bit different. In our second Google-y post of the week, there’s the news that Chrome now embeds Flash directly in the browser, starting today with the developer channel builds of Chrome.

While this doesn’t change the game for developers–it won’t materially impact Flash market share–it certainly provides a much more pleasant integration for users who will no longer need to think about updating Flash as a separate process to updating their browsers. (And since Chrome auto-updates, it’s blissful upgrading indeed.)

Plug-ins with a Dash of Pepper

What *may* impact developers more is news of Adobe working with Google and Mozilla to create a new, deeper browser plug-in API. While no timelines are given, some technical details are provided via a Mozilla Wiki page.

Code-named “Pepper”, the API provides all kinds of goodies denied to plug-ins before, such as using native GUI controls inside of a plug-in (i.e., scrollbars) instead of being forced to render its own and access to printing and the clipboard. Pepper also provides granular media APIs instead of forcing plug-ins to deal with graphics and audio on its own.

It will be interesting to see how successfully such an API can be implemented consistently cross-platform, but at first glance it seems to embrace about the right set of trade-offs.

Posted by Ben Galbraith at 9:00 am
17 Comments

+++--
3.1 rating from 45 votes

Wednesday, March 24th, 2010

MooTouch: jQTouch has a Moo-y contender

Category: Mobile, MooTools

Jacky Nguyen was behind a new website ExpatLiving from Singapore, and as he built out a nice view for iPhone and mobile Webkit folks, he implemented MooTouch. It is still in an early stage, and is asking for input:

MooTouch is a cutting-edge JavaScript framework built on top of MooTools that truly brings the experiences of iPhone / iPod Touch native applications to web applications. It is extremely lightweight and highly extensible, designed as a collection of loosely-coupled MooTools classes to handle all users’ touch interactions. Key features include:

MooTouch.App

  • Full Ajax experience, dynamic content loading on demand, ZERO page refresh or re-direction
  • Location hash handling
  • History management, makes full use of the browser’s back and forward buttons
  • Pages transition using Mobile Safari’s native CSS3 GPU acceleration
  • Automatic hiding of the browser’s location bar
  • Global event delegation to boost performance, and much more…

Some key behaviors that make the core of MooTouch:

  • MooTouch.Clickable: No more infamous 300ms delay before the “onClick” event is actually fired!
  • MooTouch.Scrollable: CSS position:fixed not possible on the iPhone? It was yesterday! Have full control over which content area you want to provide the simulated scrolling feature, with scroll indicators, deceleration & snapping back to boundaries features.
  • MooTouch.Swipeable: Bring “onSwipe” event to any DOM element you like, that’s how the photo gallery was done
  • and more to come…

MooTouch is different from most existing similar libraries thanks to the use-at-will architecture of MooTools. You can simply just pick the pieces you need and combine them the way you like. Also, you can use any existing interface framework like iUI, iWebKit, UiUIKit, etc. for styling and put MooTouch on top to control all users’ interactions with any DOM element.

MooTouch is currently still in alpha testing. It will be released under the Open Source MIT License as something I can give back to the great open-web community! All feedbacks are very much welcome.

Posted by Dion Almaer at 6:06 am
33 Comments

++++-
4 rating from 42 votes

jQuery UI 1.8 comes with new plugins, effect, and fixes

Category: jQuery

jQuery UI 1.8 has been released and it contains new plugins, a new effect, bug fixes, and is forkable on GitHub

What’s new?

Position utility

Position any element relative to any other, or even relative to the window or the mouse. In true “Write Less. Do More” fashion, it’s a simple as selecting the element you want and saying which part of it should be positioned relative to which part of another element. Bam.

Button widget

The button widget creates a themable button from any imaginable element you might be using as a native button. Progressive enhancement all the way. Now your <button> will look like your <input type=”submit”> will look like your <a class=”button”>. We updated jQuery UI widgets that have buttons, such as Dialog, to use the button plugin when you’ve opted to include it. Otherwise, they’ll remain native button elements. Again thanks to PE this is as unobtrusive as possible. Thanks to Filament Group for figuring out how to do this and Jörn Zaefferer for making it happen. And of course the community as a whole for providing feedback during early design/dev and later dev/testing. We’re stoked about having pretty form elements, and button is the first step.

Autocomplete widget

Now you can make any text input pop up a menu to aid the user in completing a text entry or search box, providing suggestions or allowed values. The autocomplete is designed and built based on the popular Jörn Zaefferer’s Autocomplete. As with the button widget we’ve kept the API as minimal as possible while providing the hooks necessary to customize it based on your needs. For example, you can provide static local data using the source option, or provide a callback function as the data source which can handle getting data from a server via Ajax. Single option, overloaded. This is the new way we’ll be writing and refactoring all of our widgets going forward, and we’re excited to hear what people think. It’s quite a change, but should keep the library lean while still as flexible and powerful as possible.

Posted by Dion Almaer at 12:16 am
6 Comments

+++--
3.8 rating from 55 votes

Friday, February 26th, 2010

ZooTool by MooTool(s)

Category: MooTools, Showcase

Bastian Allgeier has developed a beautiful, native looking web application called ZooTool.

Zootool is a visual bookmark tool for images, videos, documents and links. It is completely based on Mootools, even though it looks more like a Cappuccino app!

Play with it. Enjoy it.

zootool

Posted by Dion Almaer at 6:25 am
10 Comments

++++-
4 rating from 42 votes

Thursday, February 25th, 2010

Are you feeling touchy?

Category: Mobile

Reposted from my personal blog where I tinker with the Web. I tweet about this stuff here.

As you move to a new platform, it is interesting to watch your brain morph over time. I remember switching from Windows to Mac. At first the fonts looked blurry and weird. The mouse pointer didn’t weight right. The constant app menu was strange. There were things I liked about it right away, but they were mostly the fact that I had a command line, and the fact that apps were minimal, pretty, and useful.

Over time though, I grew to like the Mac more and more. A few months in and it was the Windows fonts that looked too sharp and weird.

I am going through the same experience with webOS and the iPhone. It took me awhile to get used to the back gesture on webOS and not look for a back button. Now I know how to organize my multiple windows, and use universal search as my quicksilver, and so much more. When I open up my iPhone now I am at the point where I try to do a back gesture by mistake. webOS is a touchier, needier device, and as I develop apps and play with the platform, I start to grok that more and more.

Embrace the touch

I discussed touching and horizontal scrolling awhile back, but the more I play with touch devices, the more I find myself wanting to build features for the touch. I have a ton of learning, but here are some of the lessons so far:

Native UI or Immersive UI

One decision that you have to make when you start building your application is the style of UI. Do you want a native looking UI for the given platform?

native-immersive-ui

Everyone jumped on native off the bat. We quickly saw libraries such as iUI come out that let you mimic the iPhone UI. Having a native UI can be important. You want to fit in. However, we have also seen the growth of immersive UIs. Convertbot is the example above on the right. It is task based and you feel like you are really interacting with the app. It is almost tactile.

gmail-nativemail

It is interesting to compare the Gmail and native Mail client UI in webOS. The Gmail version is deployed via a website, whereas the native version is of course an application, but they are very similar. Both use HTML/JS/CSS. Both have their look and feels. Do you try to look like your website (e.g. Google look and feel), or do you try to go fully native. The blending of the two gets interesting. Your brand has to live in another native world.

Haptics and touch feedback

It is usability 101 to make sure that you are always giving users feedback on their actions.

First, how do we signal to users that there are particular touch areas? This one is a bit of an art. We don’t really have :hover and the like. I actually like the idea of having a long press show helpful information, but users aren’t used to using that ability yet (see: need more gestures!).

Where we do have touch areas, we need to make sure to have various depress states for the touch.

Users will touch all over the app, so think about what you can do where.

We are going to see haptics in the future. For now it feels like haptics are used like this:

james-haptics-robot

But the science is coming along. Sony Ericcson has a device (Satio) with haptic support for example:

sony-satio-haptickeyboard

Using the Keyboard: Software or hardware

This brings us to keyboards. What is the optimal input for your application use cases.

keyboards

Feathers by Aral Balkan is a good example of both the task based nature of mobile apps, and custom software input. I like how Aral thought to create an app that solely creates Twitter messages. He didn’t create a full Twitter client that would do it all.

And if you have the pleasure of a hardware keyboard, how can you use that beyond the obvious inputting of text fields. The beauty of a keyboard that come out is that it doesn’t take away space from the screen. Could you offer short cut keys in the app? Different navigation? There is a lot more to explore here.

Gestures. Time to catalog and create new standards

gestures

We are seeing more and more gestures in applications. It feels like we are building out the standards right now. What will be the Ctrl-C’s of mobile? We get to build out invisible ways to navigate.

Tweetie 2 did something interesting when it threw away the refresh button and replaced it with the pull down. Isn’t it more work? Some people don’t like it (Jimmy Fallon for one!) but a lot of people find it more gratifying because it is more natural. We have buttons in the real world, but the apes in us are more used to touching the world around us in very different ways? This is one example of going back to our roots.

shake

Speaking of reload, we are seeing another common gesture here too. Using “shake” to reload, or relayout.

Orientation: Try to accept them, and be more creative

orientation

Have you ever turned your device on its side and not seen anything happen? That frustrates me. At the least, we need to rotate the UI and let it continue. But, can we go beyond that? I have been playing with this. What if landscape brings a more immersive experience?

Take an app that loads a stream (e.g. Facebook, FriendFeed, Twitter, whatever). In landscape, you can view one entry at a time. If the type of entry contains a photo album say, take over the full screen to show the photos and let you flick through.

It really is fun to play with touch apps these days, and I get the feeling that we are still in the dark ages wrt our interaction models.

What patterns have you enjoyed in using and building mobile apps?

Posted by Dion Almaer at 5:20 am
3 Comments

++---
2.8 rating from 17 votes

Tuesday, February 23rd, 2010

Mouseovers on Touch Devices

Category: Apple, Editorial, Flash, iPhone

Most of the thinking on iPad’s exclusion of Flash has been focused on battery life, performance, stability, or control of the application market, but here’s a Flash developer who’s thinking differently. Morgan Adams argues it’s all about the mouseover, and he raises a point that is just as relevant to rich Javascript apps.

Many (if not most) current Flash games, menus, and even video players require a visible mouse pointer. They are coded to rely on the difference between hovering over something (mouseover) vs. actually clicking. This distinction is not rare. It’s pervasive, fundamental to interactive design, and vital to the basic use of Flash content. New Flash content designed just for touchscreens can be done, but people want existing Flash sites to work. All of them—not just some here and there—and in a usable manner. That’s impossible no matter what.
….
Mouseover examples:

* Video players where the controls appear on mouseover and hide otherwise. (This seems to be the norm, in fact. Whereas a click on the same video does something different: usually Pause. Try Hulu for instance.)

* Games where you steer with the mouse without clicking (extremely common).

* Menus that popup up subpage links when you mouse over a main button, vs. going directly to a main category page when you click.
….

He claims all the alternatives are unsatisfactory, e.g. re-coding every application manually, introducing gestures, substituting double-clicking for clicking and clicking for mouseovers.

The issues are relevant to Javascript developers; for example, PPK has previously speculated on the demise of mouse* events, as well as hover in touch environments. How will that play out with a web app that relies on them?

It’s a bit like Dion’s recent tweet: “I find myself typing click^H^H^H^H^Htap 20 times a day at the moment. Is there a term that abstractly could mean both? :)”. We can get away with simple substitutions with straightforward web apps maybe, but it gets a lot more complicated with seriously rich interaction styles, the kind traditionally seen in some Flash games and now possible with Javascript. We tend to think of mobile device design as a matter of massaging the look with some CSS…the harder part to get right is often the “feel” in the look-and-feel equation. Platforms, like the web, which want to support multiple interaction styles, need to provide ways to ease the transition for developers, automating degradation and enhancement in the first instance, but allowing application designers to customise further for each device. Dan Saffer‘s sideshow below makes the point well, regarding gesture design in touch devices:

Posted by Michael Mahemoff at 2:35 am
14 Comments

+++--
3.4 rating from 26 votes

Friday, February 19th, 2010

TeX line breaking algorithm in JavaScript

Category: JavaScript, Library

Bram Stein has done some really fun work. He has taken the Knuth and Plass line breaking algorithm and implemented it using Canvas:

The goal of this implementation is to optimally set justified text in the new HTML5 canvas element, and ultimately provide a library for various line breaking algorithms in JavaScript.

You can see the subtleties at work:

justifycanvas

Check out the linebreak code which does more than solely justification. It can also perform all sorts of alignment with an appropriate selection of boxes, glue and penalties. It is also possible to give it varying line widths to flow text around illustrations, asides or quotes. Alternatively, varying line widths can be used to create interesting text shapes.

Posted by Dion Almaer at 6:57 am
8 Comments

++++-
4.4 rating from 21 votes

Wednesday, February 3rd, 2010

User scripts becoming more portable with Greasemonkey support in Chrome

Aaron Boodman created Greasemonkey back in the day. He also worked on Gears. And most recently he created Chrome Extensions. I have a funny feeling that folks were pinging him daily “hey, when ya gunna give me Greasemonkey on Chrome” and he just delivered:

One thing that got lost in the commotion of the extensions launch is a feature that is near and dear to my heart: Google Chrome 4 now natively supports Greasemonkey user scripts. Greasemonkey is a Firefox extension I wrote in 2004 that allows developers to customize web pages using simple JavaScript and it was the inspiration for some important parts of our extension system.

Ever since the beginning of the Chromium project, friends and coworkers have been asking me to add support for user scripts in Google Chrome. I’m happy to report that as of the last Google Chrome release, you can install any user script with a single click. So, now you can use emoticons on blogger. Or, you can browse Google Image Search with a fancy lightbox. In fact, there’s over 40,000 scripts on userscripts.org alone.

Not all of the scripts will work. The deeper the integration, the less chance of success. We now have user scripts supported in a variety of browsers, and hopefully they get more and more portable.

If browsers could surface the functionality to mainstream users, good things could happen beyond us power users.

Posted by Dion Almaer at 4:38 am
4 Comments

++++-
4 rating from 28 votes

Tuesday, January 26th, 2010

JavaScript running on the GPU

I love programmers like Alex Miltsev. He won the Jetpack 0.5 content by prototyping access to the GPU from JavaScript!

Alex’s work is an alpha-prototype that shows the feasibility of the project and it requires a custom build of Firefox to use — it’s not easy to demo. However, the code sample below shows how the technology works. In this example, we are transposing a matrix at lightening speed:

jetpack.statusBar.append({
html: “Transpose!”,
onReady: function(widget){
$(widget).click(function(){
var myStorage = jetpack.cuda-storage;
var matrix = new Array();
var size = 32;
for(var i=0; i

Alex discussed why this matters:

People are using the internet to collaborate more than ever before. Collaboration on the internet has been evolving at a rapid pace, and the applications and technology that will drive the next wave of internet collaboration will require even greater technical complexity and more significant computing resources than is currently available through the browser environment today. While text documents, videos, music, and image-base forms of collaboration are now common place, there are many needs require a level of compute performace beyond the web platform as it exists today, such as:

  • consumption of high-quality digital video or music streams,
  • complex image or speech recognition,
  • manipulation and processing large pictures of nature or space,
  • processing large sets of tabular data locally in the browser,
  • complex animations with DOM elements (via DirectX or OpenGL),
  • exploring 3D worlds, such as SecondLife or an OpenSim Grid,
  • real-time audio and video editing,
  • having an integrated development environment that runs entirely in the browser

There are endless examples of such complex uses of the internet platform that are just not feasible with the status quo web platform. Developers have tried to overcome such barriers in the past with client-side enhancements like ActiveX, Netscape Plugins, Java Applets, but each in its own way was flawed and failed to gain mass adoption. It is possible that the Native Client project will change all this, but standardization of such initiatives across the browser landscape is a lengthy endeavor. For the near future the tools that the developer uses to provide a rich user experience remain JavaScript and ActionScript, plug-ins, such as the ones previously mentioned, are significantly limited by the architectural mismatch of performance requirements they place on the CPU.

Ben tends to get a little giddy when he hears about GPU access :)

Posted by Dion Almaer at 12:07 pm
15 Comments

++++-
4.6 rating from 29 votes