Japan Display has developed a prototype 651ppi LCD panel. First announced in June 2012, this display has a resolution of 1280x800 pixels, equivalent to that in a regular notebook PC, but in a screen size of only 2.3 inches
Now imagine an iPad mini equipped with one of those.
Local storage is a powerfull tool to cache data computed by web apps for later reuse or non critical persistency1. For example I do used it on a recent project, to reduce both the data loaded from the server and the computational cost of sorting a huge list of articles by filters.
Cause the local storage will persiste on the browser for a long time to safely use this data we have to be sure that they are reliable and up to date. Usually the data can get useless for two main reasons: they are based on data produce by the server, that has been updated; or they have been stored by a previous version of the web app which data model have long changed.
To check the data against the server a good option is to have it provide a timestamp2 for the latest time the data have been changed.
If the web page, is rendered by the same server we are getting the data from, we can pass this information around as a Custom data attributes in the DOM element that hold the app.
<div id="appHolder" data-timestamp="2012-10-02T20:17:08.780Z"></div>
Otherwise, if the data are coming from a different server, we can get the information as a lightweight JSON.
{"updated": "2012-10-02T18:30:30.179Z" }
To match the data against an updated version of your app the best option is to have a the version number as constant in your app namespace, and save it with your data on the Local Storage.
myApp = {}; myApp.VERSION = "0.0.4";
It’s best to run this test as soon as the app is inited, if both of this test succeed you are usually safe to trust the stored data, otherwise it’s reccomended to recreate it.
With non critical persistency I intend any kind of data that can be reconstructed without causing damages or requiring serius effort from the end user. Like a precompiled set of filters for a search.
Although not mandatory I reccomend you to store this data in the ISO format “2012-10-02T20:17:08.780Z” to better reuse it in javascript passing it as an argument of a new Date object. ↩
The first time I’ve stumbled upon the middleware pattern it was in Express.js, while developing the backend for Gestalt.
The concept of middleware it’s quite straight forward, it’s nothing more than a function that handle a request. What make it so interesting is the possibility to create a stack of middleware. By doing so each middleware will be able to process the request, and call the next one in the stack.
A typical middleware will look like this:
var foo = function(req, res, next) {
// all your logic goes in here
// proceed to the next middleware
next();
};
If a middleware have to signal an error, it can do so passing it to the first argument of the next().
var bar = function(req, res, next) {
// signal an error
next( "Something went wrong!" );
};
To append a stack of middleware to a request in Connect you have to declare them with the use method1.
// Example from http://www.senchalabs.org/connect/
var app = connect()
.use(connect.logger('dev'))
.use(connect.static('public'))
.use(function(req, res){
res.end('hello world\n');
})
.listen(3000);
What I really like about this pattern is that by simply reading the use stack you can get a grip on the logics behind the application. Also structuring your application as a cascade of middleware you are encouraged to split it in small, self contained, modules and avoid nasty callbacks. With the added benefit of a enhancing both the readability maintainability of your code.
PantaRhei.js is my front end implementation of the middleware pattern . I structured it as an extension for Backbone.js because it is awesome, I’m using it on the wast majority of my projects, and I want to leverage it’s Events module and the simple inheritance style provided by the extend() method.
PantaRhei is written in CoffeeScript and distributed with the MIT license. You can find the coffeescript sources and the compiled and minified javascript files on Github.
The purpose of PantaRhei is to ease the creation and the execution of queues of tasks, like fetching and manipulating data, managing the transitions between pages and so on. Right now PantaRhei is composed by two modules: the Flow, that is responsible for the execution of the queue and the Worker, that describe one of the possible structure of middleware2 that the Flow can handle.
The Worker module is more a convention than a real module, and it’s meant to be extended. It describe two methods: the former is the run it’s invoked by the Flow to execute the worker and accept a shared object ( which purpose is to act as a place for workers to share data ) and the next callback as arguments; the latter is the kill, that is invoked by the Flow when the worker execution is completed to safely remove it. The worker constructor also accept an option id as an argument.
To create a new Worker you need to extend it and implement it’s methods:
var Delay = PantaRhei.Worker.extend({
constructor: function(duration, id){
this.duration = duration;
this.id = id;
},
run: function(shared, next) {
onTimeout = function(){
next();
};
setTimeout(onTimeout, duration);
},
kill: function(){
// all your logics to remove the worker
}
});
var shortDelay = new Delay(1000, 'shortDelay');
PantaRhei also include, under the PantaRhei.workers namespace, a series of workers3 JsonLoader and LoadAssets.
The Flow module is our middleware manager, and handle for you all the logic to create and run the queue. To create a new flow all you have to do is to call it’s constructor and optionally pass two parameters: an id and a array containing the list of workers to use.
var flow = new PantaRhei.Flow( 'myFirstFlow', [task1, task2] );
You can also append a worker to the flow passing it as an argument of the use method.
var task1 = function(shared, next){
console.log( "task one completed" );
next();
},
flow = new PantaRhei.Flow( );
flow.use(task1);
To execute the flow you have to invoke the run method. The flow can also accept an optional shared object. This is passed around to all the workers in the queue and it’s returned by the flow on complete, it’s actually the place for storing and passing data between workers. If this is not provided the Flow will create a empty object to use.
// create our workers
var task1 = function(shared, next){
shared.data = "the data have been processed"
next();
},
task2 = function(shared, next){
shared.newData = "we got some new data for you"
next();
},
// create our flow and workers passing the first task on the constructor
flow = new PantaRhei.Flow( 'myFirstFlow', [ task1 ]);
flow
// append the second task
.use( task2 )
// run the flow
.run({data: "the data is new"});
PantaRhei make use of the Backbone Events, so the Flow can dispatch the following events: run, pause, resume, error and complete. Apart from the error all the other events pass the shared object as an argument to the listener. So to get notified when a flow have been successfully executed you can catch the complete event. “`javascript var onComplete = function( shared ){ console.log(shared); };
flow .on( ‘complete’, onComplete) .run(); ”`
PantaRhei leave the responsibility to properly handle the errors to you. If any of the worker in the queue pass and error to the next callback, the Flow is paused and dispatch an error event. Once you have done with the error handling and you are ready to resume the flow you can call the resume method to move to the next worker in the queue.
var onError = function( err ){
//handle the error in here
this.resume();
};
flow
.on( 'error', onError)
.run();
The other one is a simple function that accept as arguments the shared object and the next callback.
Recently there have been a lot of disillusionment about a series of successfully backed Kickstarter projects who failed to ship. Therefor Kickstarter decide to clarify their position and enforce a new series of rules especially targeted to physical product.
It’s hard to know how many people feel like they’re shopping at a store when they’re backing projects on Kickstarter, but we want to make sure that it’s no one. Today we’re introducing a number of changes to reinforce that Kickstarter isn’t a store.
While the Risks and Challenges section is a correct move, I have mixed feelings about the new measures for Hardware and Product Design projects. Surely demanding a working prototype is a step in the right direction, but completely prohibit the 3D rendering is a poor choice. And neither of this help backers to understand if the product they are going to support can be realistically manufactured.
A working prototype is a necessary step for the creators to figure out how o produce a real product out of their amazing concept. But it’s not enough to assure the backers that it’s actually possible produce the same product in large quantity, leveraging industrial facilities, neither it’s a good estimation of the real production costs—which can also vary by a significant amount based on the number of peaces that are going to be manufactured.
Especially for complicated products that require a combination of different technologies and draconian manufacturing and distribution lines1.
The case against rendering is a complete non sense to me. Simulations and renderings are powerful tools for creators both to design and iterate the product and to show the backers what the product it’s going to look like and the possible colors and trim customizations.
An interesting point Kickstarter raise in their post is to fix to one the amount of quantities that a project can offer to a single backer.
Offering multiple quantities of a reward is prohibited. Hardware and Product Design projects can only offer rewards in single quantities or a sensible set
This kind of choice make sense considering that over a certain amount of product to produce it could become necessary to reconsider the entire manufacturing line—that could not be convenient probably till a new order of magnitude is reached—and keep manufacturing the product using a line produced for smaller quantity is not always possible or desirable.
This kind of consideration also open the road to another possibility, a founding cap. Clearly this is not something Kickstarter should force to the product, most of the projects founded don’t have real issues with over founding, but could be a nice option that the creators can decide to adopt.
Even better would be to have progressive founding goals; it’s quite a common practice, for creators, to promise increased sets of features based on the amount of money (over the initial founding goal) the project manage to raise2. Kickstarter could officially support this kind of initiative by charging late bakers only when the next goal is reached.
I do honestly doubt that the Ouya will ship in time for Mar 2013. ↩
The Planetary Annihilation project had an interesting take on this, adding game enhancements and orchestral sound track. ↩
Sad but true Bill Moggridge passed away at the age of 69. Among the other things he was the designer of the first laptop. If it’s work it’s unknown to you please do yourself a favor and read Design Interaction.
Great news for those among us who wish to bring more exciting effects on the web. Adobe’s CSS Shaders proposal have been approved approved by W3C as a part of the Filter Effects. For the ones new with the matter here is an introduction and a series of examples1
Based on Erik Loyer’s slabtype algorithm SlabText is a nice jQuery plugin to achieve the popular slab header effect. I especially like to be able to manually set word combinations and the possibility to set a break point, to disable the effect, if the view port reach a chosen minimum resolution. Get the source on github
If you are interested in javascript and typography you should also check Paravel’s lettering.js to fine tune each single letter of a given text.
