There are a substantial number of iPhone apps that tie into the builtin native components such as the camera.
Brad Lassey has been hacking on Fennec (the Mozilla mobile browser) as well as Firefox itself to integrate with camera phones and Webcams alike:
I wrapped a video tag, image and a few buttons in xbl and bound it to <input type=”camera” />. When a user hits a website using this tag, he or she currently will see a live video preview and a “take photo” button. When the user clicks the button, the photo is grabbed from the camera and shown to the user in the image element. The image element and video element are in a deck element so only one is shown at a time. After the photo is taken, there is a button that reads “Take another photo,” in case the user doesn’t like the one they just took. Once the user is satisfied, this element works like any other form element and the file can be uploaded to a web service.
After talking to a few people this should actually be bound to <input type=”file” accept=”image/png”/>. Also, it needs some UI design both for what it looks like in content and for a configuration dialog. Finally, we’ll need to think about security and make sure no one can snap a photo of you when you’re not looking your best.
I kinda like having an input type="camera" myself, to be more explicit. It would be cool if you can get access to the image as data (e.g. the value is data:......). I love it.
Azer Koculu has released his Pi.js framework, which is a lightweight system that includes a minimal set of modules, and the ability to use and provide plugins.
By default you get:
pi.env: browser detection
pi.get: DOM access
pi.util: Extensions to JavaScript (e.g. support currying, includes, viewport config, and more)
pi.base: OO subsystem
pi.element: Create and modify the DOM
p.xhr: Remoting
Extensions to native objects such as Array, Function, Number, and String
Kris Zyp has created OfflineRest, a new module in Dojo 1.2 that allows for a simple offline pattern to building your application.
Dojo 1.2’s new dojox.rpc.OfflineRest module automates the local storage of data and synchronization by leveraging the Dojo Data and REST abstractions. The OfflineRest module augments the JsonRest service in Dojo such that requests are cached in local storage for offline access, and modification requests (put, post, and delete) modify the cache and are recorded for delivery to the server; immediately if online, otherwise when connectivity is restored. Furthermore, JsonRest is the core engine used by JsonRestStore. Consequently, you can simply use the standard Dojo Data API with the JsonRestStore and effortlessly add offline capability with no modifications to your data interaction code. The underlying Rest service automates the handling of caching, storing data locally, and syncing changes. In addition the new OfflineRest module has no dependency on plugins, but rather progressively utilizes offline features that are available, while still operating properly on legacy browsers without offline support.
He has a demo that involves a CRUD system for hiking trails which interestingly asked me for Gears permission, even though it appears that OfflineRest doesn't abstract on top of both Gears and the emerging storage standard, which is something I would like to see, to extend the reach.
First, we have his interactive learning area where the presentation is just a JavaScript application that you can play with. Double click on the code, make a change, and save away!
The talk goes into the innards of the language that we are know, love, or at least deal with:
Defining Functions
Named Functions
Functions as Objects
Context
Instantiation
Flexible Arguments
Closures
Temporary Scope
Function Prototypes
Instance Type
Inheritance
Built-in Prototypes
Enforcing Function Context
Bonus: Function Length
The goal of all of this, is that after going through the presentation you should understand the following:
I am a strong believe in making the keyboard a first class citizen for your applications, including on the Web. Thus, I was interested to read how Ext JS has keyboard handling that ties into the entire system:
Ext.KeyMap
Ext provides several components that support keyboard navigation out of the box such as GridPanel, ComboBox, and TreePanel. To implement custom keyboard handling, developers can use the Ext.KeyMap and Ext.KeyNav classes to attach keyboard bindings to any component or element they wish.
The first set of keys we wanted to handle was all of the Function keys (F1-12). While most browsers reserve some/all of these keys, with some ext-pertise, we are able to override the default function if need be for our application. The application we were working with was completely dynamic and server driven, so we really couldn’t define all of the handlers ahead of time. This led to us dynamically building an array of key handler configuration objects and passing them all through to our new Ext.KeyMap object.
Many years ago I stumbled across the original BrowserHawk. Back then, it was primarily a way to feed information about a client's web browser to a server-side web framework. I was impressed at the time with its ability to detect display resolution, color depth, and a variety of other data not available via HTTP headers.
Richard Litofsky wrote in to tell us that BrowserHawk lives on in a new form: BrowserHawk To-Go. It sounds interesting, though not as revolutionary today as it was to me back when embraced complete ignorance of client-side browser programming:
BHTG is a complete rewrite of our classic BrowserHawk product and is
specifically designed for cross browser, JavaScript-centric programming.
By including our BHTG JS library developers can add our robust browser
sniffer that detects over 100 different properties including browser
type/version/platform, connection type and speed, latency, installed
plug-ins, blocked popups, Java settings, and more. This data can be logged
and/or used to dynamically control page behavior.
BHTG also can add an automated browser troubleshooting and self-help page to
a web site, again just by including the JS library. It also can, with one
line, monitor the *actual* page load times experienced by each user to a
site. And it reports any JavaScript errors users encounter on the site, with
customizable match rules.
BrowserHawk To-Go is a commercial product; they're going for a Software-as-a-Service model where their servers host the script (à la Omniture, etc.).
As a follow-up to our recent posting of a JavaScript Pac-Man clone, we bring you a JavaScript Space Invaders clone: Invaders from Mars. Only this time, in addition to a link to the game itself, we've got a link to the author's blog (one Mark Wilcox) in which he goes into detail on the various design issues he faced whilst creating his game and discusses the lower-level framework he created to drive his game.
Invaders from Mars does it old-school, as did the Pac-Man clone: divs and images, baby. Performance is pretty good, but I can't wait to see people realize that if they go with <canvas>, they can really do some interesting stuff. What do you think on the Canvas vs. DOM rendering model for games, etc.?
Dealing with data is one of those areas of software development that we haven't quite gotten right yet; anyone who tells you otherwise is selling something (or has developed an open-source framework). Whether you embed SQL in your code, map objects to data via some kind of tool, mash it all up LINQ-style, or go all sci-fi with funky XML-all-the-way-down tools, each approach has a series of trade-offs and compromises that just don't feel right.
Kris Zip, a researcher with SitePen, is throwing his hat into the ring with efforts he and others at SitePen are leading to provide Ajax developers with a fully coherent JSON stack. That is, frameworks and services that allow developers to deal entirely in JSON from the bits on the disk to the data on display.
In Audible Ajax Episode 30, Kris chats with us about the JSON work in progress, a bit on his background, and a discussion of the talks he'll be giving at the Ajax Experience next week that covers some of this material.
Christian "Mr. Canvas Effects" Effenberger has shared Sphere.js another effect that allows you to add a spherical picture effect (including background gradient) to images on your web pages.
This joins the many other effects such as Slided and Filmed.
As always, you can add these effects with simple CSS classes on the images.
Dave Johnson calls PhoneGap "AIR for the iPhone" because this nice little hack, first created at an iPhone BarCamp, wraps the Web view with a container. This container gives the view access to APIs available on the device, that may not be available yet via WebKit alone. AIR provides a similar container for Flash and Ajax content on the desktop.
PhoneGap is a free open source development tool and framework that allows web developers to take advantage of the powerful features in the iPhone SDK from HTML and JavaScript. We're trying to make iPhone app development easy and open. For many applications a web application is the way to but in Safari you don't get access to the native iPhone APIs, and the that's the problem we're trying to solve.
It is written in Objective-C and allows developers to embed their web app (HTML, JavaScript, CSS) in Webkit within a native iPhone app. We're big advocates of the Open Web and want JavaScript developers to be able to get access iPhone features such as a spring board icon, background processing, push, geo location, camera, local sqlLite and accelerometers without the burden of learning Objective-C and Cocoa.
PhoneGap also has a web app that allows web developers to quickly package their web app into a native iPhone app by providing a URL, a name and icon graphic the web service with automagically create a native iPhone application. We haven't open sourced that code but we're going to soon.
PhoneGap was conceived at iPhoneDevCamp II by Nitobi developer Brock Whitten, Rob Ellis, freelance designer Colin Toomey and Eric Oesterle.
There are a few APIs available now, and others pending:
SproutCore jumped onto the scene when MobileMe launched to much acclaim on the visual side (even if the back end couldn't handle the load).
It doesn't seem to be a one-hit wonder, especially in the field of e-mail. OtherInbox "provides consumers with a free email account that automatically organizes newsletters, social networking updates, coupons and receipts from online purchases", and showcases SproutCore again.
If you are looking to build desktop-looking applications, it is worth giving SproutCore a look.
Auto-rendering: a new PURE method takes your HTML and your JSON data and merges them automatically. The class attribute is used to map the HTML and the data. (Read more about autoRender and its jQuery version on our Wiki).
Joe Walker was thinking about accessibility and wrote about a thought experiment that he had where he ponders 'What if we didn't lump all "accessibility" requirements together?'
What if, instead, apps are written for one audience. What could you do differently for different use cases?
Designing for Screen Readers
So you want to create a version of your site specifically for screen readers, ignoring everyone else. What might you do?
Scroll bars are generally bad for sighted people. They hide content, slow things down, and some people find them hard to use. But screen readers don't care about long pages; the scrollbars are invisible anyway. So how about packing the whole site into a single page? Since the graphics are irrelevant, we can skip those, and for many sites still have less to download. The page can then start with a description of the access keys and the user can then navigate really quickly. We could quickly summarize the access keys at each page boundary in case they've been forgotten.
Designing for Dyslexia
Dyslexia is generally less of a barrier to web use compared to blindness, however it is very common and often overlooked. In contrast to the low graphic, high text approach for Screen Readers, some dyslexics think in terms of pictures, and may prefer a layout which uses a standard set of icons to back up common concepts. Many users without this disability may find this approach distracting, and it's certainly going to be annoying to anyone with a screen reader, if the text goes on regular side-tracks reading the ALT text that is only there to back up the text anyway.
Designing for Cognitive Disability
One of the problems with the web, and computers in general is the level of distraction. Distractions are a problem for everyone whatever their abilities, but the problem is exacerbated by disability. I've noticed that as people slow down, they start to look around at their screens using their neck muscles, pointing their entire head rather than just their eyes, and I think it's all about focus. We need a way to narrow our focus to concentrate on the important questions.
It might be possible to have a site where we could "zoom in" on what was important. If you could "zoom-in" to simplify GMail, what would you throw out? Invitations would go, as would links to other services, settings, maybe labels and the 2 sets of buttons that do the same thing. I think many people use email by just seeing their inbox, and maybe search. Ultimately email could be a wizard where you see what's new and that's it. Clearly this lack of detail isn't going to be good for everyone, but having a "simplify it" function could be really useful in many cases.
Designing for Low Vision and Motor Impairment
I don't know, but I suspect that the "zoom-in" to simplify concept is going to require lots of complex layout. In comparison to which, people with low vision or motor impairment want simple layout. They also want to zoom in, but probably just to make the words/buttons bigger. People with low vision often differ in how they need the screen enhanced. Is it black/white or white/black. Have colors gone, or might a flash of yellow help? Often the OS takes care of much of this problem, but websites that use yellow-fade might be helping, or might not, depending on OS settings. Good design for low vision is probably going to let the user select the type of visual aid that helps.
Of course, this sounds interesting in theory, but we have the sliding scale:
How many developers build for more than one browser, let alone...
Old browsers, let alone...
Accessibility, let alone...
Multiple accessible sites.
Christian Heilmann talked about having a movement for accessibility, and how we need to not be flailing in the wind.
, Component
