The web used to be composed of simple pages. It still is, to a degree, but less and less so. For example, Wikipedia is the active giant still spewing forth pages rich with information. There are plenty of news sites, and blogs just like this one that I wouldn't consider applications. But less and less so. Instead, we're craving the interactivity brought about by applications. The information is still there, just arranged, and curated differently. Instead of a monolithic blob, such as this post, the pieces of information are fragmentary. Not necessarily incomplete, but defined by a work-flow different from what we're used to. Will there be a need for pages in the future when the web is composed of powerful applications that allow us to better carve out the chunks we need at that moment?
Showing posts with label web. Show all posts
Showing posts with label web. Show all posts
Monday, February 25, 2013
Thursday, September 8, 2011
Themes: The New Web Resource
Web resources are an integral part of web applications. So what exactly is a web resource? A web resource, generally speaking, is anything returned by an HTTP request. For example, HTML pages are the quintessential web resource. But there are other resource types too — images, CSS style sheets, etc. The browser depends on these resources to properly render the page for the user. So in this sense, what the user sees is actually a decoupled collection of smaller resources.
A few resources are more prevalent than others — HTML, CSS, Javascript. But the fact of the matter is that anything can be a resource — data a remote agent solicits or modifies. We're not limited to what we can serve — can make available to clients. There is no predefined set of resource types.
With the ever growing complexity of applications, the limitless dependencies required to make the thing work — introducing new composite resource types is a foremost advancement toward a better web. Themes are like web pages — a composite type of resource — one that'll be ever more germane to web applications over the next couple years.
Why resources?
So why do we call the things we retrieve with HTTP requests resources? Why not call them web objects or files? The term resource has more to do with the client software than the actual resource itself. The term resource reflects the fact that what the client is fetching is something it needs to function correctly. A dependency of sorts. For example, your television makes use of a digital content stream resource.
The term resource is especially useful when we're describing stuff that has to do with the web. Things that live on the web. The web is called the web because it's interconnected. The the nodes in this graph are the resources.
When we're talking about a particular site, we're more inclined to refer to resources by their type — the page, the image, the flash, the video. But when we're talking on a pure HTTP web-as-hypermedia level, we're better with the ambiguity resources suggest. If some application has an API that lists resources, and an API that retrieves a specific resource, we can design the client around those concepts. Resources are an architectural design idiom while specific resource types describe specific resource attributes.
Themes are abstract
Up until now, we've only touched upon the most general ideas of what makes a resource on the web. Put simply, it's any web-accessible data — you can retrieve it by issuing a GET request. But the client must know about the resource's URI — where is it? Where does the client get such information? From other resources that know about it — this is the interconnectedness that makes the web so powerful.
Now that we have this resource, how does the client know what to do with it? The web browsers people use to surf the web on a daily basis know how to interpret dozens of resource types. In HTTP terms, the resource type is the content type, usually specified in the response headers. If the client knows what the resource contains — it's structure — it can make use of it.
Imagine getting a CSV row with twenty columns in it. Suppose you've hadn't received any schema for this data. You might be able to make sense of some things in the data be deriving their meaning, but you're essentially playing a guessing game. Without a standard (schema), making use of web resources is a lost cause. Web standards dictate a common set of rules so that browsers know how to display information. This is how the browser knows that a CSS web resource is used to alter the appearance of another — the HTML page.
The HTML page and the CSS stylesheet are so commonplace that we hardly think of them as abstract anymore — but they are. They're a simplified set of instructions — more abstract than saying "this group of pixels should be positioned here and should be coloured blue". Humans know how to make sense of higher-level instructions that hide the low-level details.
But even with high-level languages like those of HTML and CSS — languages that hide the messy stuff — we're still able to build applications that are incredibly difficult to comprehend let alone maintain. Web sites and web applications are getting bigger and bigger — there is a cost to that volume. Complexity means longer development time and or more development resources.
Themes are the next level up on the abstraction ladder. A theme is simply the appearance of the site — like how desktop themes let users change the appearance of their local environment. Themes are more abstract than CSS styles because of the standards imposed on them — the same style rules are found in each theme — only the properties change.
Nothing new, just improved
You might be wondering what exactly sets themes apart from any other typical web resource we're used to. Like CSS style sheets. That is what themes are after all — a collection of styles and images. Both of these things we're used to seeing in every web page we visit.
But unlike your typical CSS that we're used to, themes carry a standardized interface HTML pages can utilize. The jQuery UI project really pioneered themes — the new resource type that we've come to expect. This is how we're able to achieve a consistent look and feel across all our applications. The standard theme interface allows this because the applications that use them must adhere to the theme styles.
Themes simply tie together older, more familiar resources that we're used to. They're more abstract, enabling us to build better user interfaces for the web. So are they justified in being referred to as a new resource type? I think so.
A few resources are more prevalent than others — HTML, CSS, Javascript. But the fact of the matter is that anything can be a resource — data a remote agent solicits or modifies. We're not limited to what we can serve — can make available to clients. There is no predefined set of resource types.
With the ever growing complexity of applications, the limitless dependencies required to make the thing work — introducing new composite resource types is a foremost advancement toward a better web. Themes are like web pages — a composite type of resource — one that'll be ever more germane to web applications over the next couple years.
Why resources?
So why do we call the things we retrieve with HTTP requests resources? Why not call them web objects or files? The term resource has more to do with the client software than the actual resource itself. The term resource reflects the fact that what the client is fetching is something it needs to function correctly. A dependency of sorts. For example, your television makes use of a digital content stream resource.
The term resource is especially useful when we're describing stuff that has to do with the web. Things that live on the web. The web is called the web because it's interconnected. The the nodes in this graph are the resources.
When we're talking about a particular site, we're more inclined to refer to resources by their type — the page, the image, the flash, the video. But when we're talking on a pure HTTP web-as-hypermedia level, we're better with the ambiguity resources suggest. If some application has an API that lists resources, and an API that retrieves a specific resource, we can design the client around those concepts. Resources are an architectural design idiom while specific resource types describe specific resource attributes.
Themes are abstract
Up until now, we've only touched upon the most general ideas of what makes a resource on the web. Put simply, it's any web-accessible data — you can retrieve it by issuing a GET request. But the client must know about the resource's URI — where is it? Where does the client get such information? From other resources that know about it — this is the interconnectedness that makes the web so powerful.
Now that we have this resource, how does the client know what to do with it? The web browsers people use to surf the web on a daily basis know how to interpret dozens of resource types. In HTTP terms, the resource type is the content type, usually specified in the response headers. If the client knows what the resource contains — it's structure — it can make use of it.
Imagine getting a CSV row with twenty columns in it. Suppose you've hadn't received any schema for this data. You might be able to make sense of some things in the data be deriving their meaning, but you're essentially playing a guessing game. Without a standard (schema), making use of web resources is a lost cause. Web standards dictate a common set of rules so that browsers know how to display information. This is how the browser knows that a CSS web resource is used to alter the appearance of another — the HTML page.
The HTML page and the CSS stylesheet are so commonplace that we hardly think of them as abstract anymore — but they are. They're a simplified set of instructions — more abstract than saying "this group of pixels should be positioned here and should be coloured blue". Humans know how to make sense of higher-level instructions that hide the low-level details.
But even with high-level languages like those of HTML and CSS — languages that hide the messy stuff — we're still able to build applications that are incredibly difficult to comprehend let alone maintain. Web sites and web applications are getting bigger and bigger — there is a cost to that volume. Complexity means longer development time and or more development resources.
Themes are the next level up on the abstraction ladder. A theme is simply the appearance of the site — like how desktop themes let users change the appearance of their local environment. Themes are more abstract than CSS styles because of the standards imposed on them — the same style rules are found in each theme — only the properties change.
Nothing new, just improved
You might be wondering what exactly sets themes apart from any other typical web resource we're used to. Like CSS style sheets. That is what themes are after all — a collection of styles and images. Both of these things we're used to seeing in every web page we visit.
But unlike your typical CSS that we're used to, themes carry a standardized interface HTML pages can utilize. The jQuery UI project really pioneered themes — the new resource type that we've come to expect. This is how we're able to achieve a consistent look and feel across all our applications. The standard theme interface allows this because the applications that use them must adhere to the theme styles.
Themes simply tie together older, more familiar resources that we're used to. They're more abstract, enabling us to build better user interfaces for the web. So are they justified in being referred to as a new resource type? I think so.
Wednesday, August 31, 2011
Widgets And Frameworks
Web frameworks are important because today, the target user environment is the web. Why is this? Because the web means anyone can use your application. There are no barriers to installing the software and no restrictions on the hardware. All the user needs is a decent web browser.
The web application framework itself is relevant because it enables developers to write solid software by reusing common components. Common patterns used in all web applications. Without these tools supplied by the framework, nothing would ever get off the ground — a diffuse time to market for smaller development teams.
What patterns are used in web frameworks? Database connectivity, URL mapping, authentication. The list goes on, each framework providing their own flavor of these major components. Each is considered a pattern because any web application needs to implement it. This quickly burdens the developer. The role of a web framework is to parameterize these patterns and make them accessible.
What role do widgets play in web application frameworks? By widgets, I mean standalone Javascript toolkits that have a selection of cool user interface stuff. This includes jQuery UI, Dojo, and ExtJS. Making these Javascript widget tool kits — which are a framework on their own — integrate seamlessly into our web application frameworks is disjointed to say the least.
Not an easy fit
Web application frameworks don't give us all the front-end browser code necessary for a finished product. If it were a matter of delivering only HTML and CSS to the browser, we'd be all set. This isn't the case unfortunately. Not if there is any kind of user interaction involved — which is almost certainly the case. For the kind of experiences users have come to expect, developers need to employ Javascript or Flash technologies.
In theory, building these rich user experiences is fairly straightforward — alter the HTML templates and serve the additional resources — Javascript, Flash, etc. This can be achieved without any headaches — granted the project is a small one. There many resources to worry about, not as big a user base compared to something enterprise-grade. Every aspect of the software is scaled back slightly — and so the cause for error is scaled back accordingly. For example, having a very large Javascript file or dozens of smaller Javascript files can be hard to maintain. Not on their own — but because Javascript is different — it depends heavily on the DOM.
So as far as the development process goes, we need sound approach to ensuring there is some degree of coupling between individual HTML templates and their corresponding Javascript modules. The days of implementing a monolithic Javascript file are quickly leaving us behind. Especially if given the challenges of managing external widget library dependencies. Imagine an application with a hundred or more HTML templates — I can't think of an optimal method where a single Javascript module suffices.
Technically speaking, uniting widget frameworks and web application frameworks wouldn't be overly strenuous. All this entails, and this is generally how they're put together now, is serving new resources and having your HTML content ask for those resources. The place where widgets don't fit seamlessly into the web application framework is in the back-end the web application. How does a given view or controller (whatever the framework terminology alludes) know about which widgets are used? Are these widget configurations persistent? For that matter, are they configurable at all from the web framework? For me this is a problem — widgets are a big part of the overall picture — web application frameworks should accommodate widget frameworks.
Frameworks and forms
A crucial feature of any software with a web user interface is forms. Forms collect user feedback. They can be simple — a single input field and a submit button. They can be complex — a registration form that nobody in their right mind would fill out. Web application frameworks do a pretty good job with tools that both render and validate forms.
There is good reason for. Web frameworks define the database schema for the application. The database is populated by user input. Forms. There is an obvious connection between the two concepts — this is why frameworks take great care to supply the database with what it expects.
Take Django
for example. The Django framework has a forms module that'll assist with defining forms, the validation, and rendering the form widgets for the browser. Not unlike how Flask uses WTForms to validate and present forms. The Pylons
project also provides developers with form processing capabilities — they require a little more effort than the other Python frameworks.
What really stands out is the connection forms and their individual input widgets have the framework itself. They're an essential ingredient to the application — a formative piece of the database. There is a mapping between the database schema and what is presented to the end user so they can populate it. This fits perfectly with the ideal of the web application framework — to take a pattern and expose it as a cohesive API for the developer. This concept is further exemplified by Django where we're able to point the form subsystem to a database model and let it figure out how the form should be rendered and validated. This isn't so easy with more general widgets that aren't necessarily used for collecting input and storing it.
Widgets and data
If we're able to utilize the framework form processing tools to store data, how does the framework help us present data to the user? Well, since a web application framework is only responsible for delivering the content to be rendered by the browser, all we've got is templates. These assist in generating the markup necessary for displaying fancy Javascript widgets.
For instance, a common user interface pattern is to group logical categories using tabs. Tabs are visually appealing and allow for intuitive navigation. This is a top-level layout widget — meant to replace a typical sidebar navigation item. Or consider a smaller widget — a progress bar. This type of widget, unlike tabs, isn't a layout container. It displays something specific about the application data.
What both layout container widgets and smaller application data widgets have in common is that they both depend on specific application details that reside on the server, within the framework. The tabs widget needs to know what specific tabs to display and what content within each tab. The progress bar widget probably depends on a computed number — derived from user data from the database. So what is the preferred approach to displaying both widget types in any given application?
Navigational constructs are typically done in the template. Maybe there is a nested div and a tag structure the Javascript widget is expecting — like the jQuery UI tabs widget. However, the developer still needs to instantiate their widget when the page loads. This means that the Javascript code needs to know about the template and what the rendered HTML output will look like. This is somewhat error-prone as the developer will need to maintain dependencies between the Javascript widgets and the HTML structure they're expecting.
More challenging is the application user data presented by widgets — like a progress bar. The progress bar needs the value to display — but where does it come from? This might be a JSON response, returned from one of the application controllers. Again, as with defining layout widgets, the problem lies in maintaining the connection between what the Javascript widget is expecting to see and what the framework delivers. The problem isn't so much technical — it is more of a design problem. One that leads to a loosely coupled system. Too loose.
Solutions and challenges
Web frameworks already do a great job of taking common patterns on the server and making tools developers can use to efficiently develop code. Might it be that web application frameworks have no business managing widgets? Should this task be left to the templates and other static files? I think there are patterns we're missing here that can be taken advantage of — it's still only an emergent thought.
One benefit to having the framework manage the connection between application data and widgets is the potential to be widget framework agnostic. There are a lot of widget tool kits out there and a lot of similarities between them. The commonalities across all toolkits — these are the interesting widgets. The basic widgets that all web applications use in one form or another could potentially be integrated into web frameworks.
What might we do with the layout widgets to help standardize and improve the coupling between Javascript and framework data? After all, layouts, if they can be standardized in some fashion, are a valuable asset. You'll generally have a web application framework of choice and you'll almost certainly be creating more than one application.
I think layout widgets — stuff specific to the user interface and not necessarily what the application does — will be easier for frameworks to implement. If the framework is able to introduce the concept of a widget, maybe storing it's configuration, then properly outputting the required markup and the required Javascript isn't a stretch. For example, the configuration for a tabs widget would store what tabs are actually rendered, the contents of each tab, and should produce the necessary Javascript to instantiate it.
Widgets specific to application data — like a grid — aren't as easy. This is because they're more toward what the application does. Another challenge is that widgets generally depend on some data source like JSON that is generated from the user data. This isn't so easy to stardardize on. The framework would have to know about the data schema in addition to the visual configuration. This means the application would have to store configuration that dictates what the widget will look like, where to get the data it needs, and how that data should be interpreted for presentation. Not impossible, just more challenging.
Perhaps a good start to making web application frameworks a little more aware of patterns in how browser widgets interact with the framework itself is to discover patterns you're using. How would you benefit if you're able to store some configuration that defines how and what the Javascript widgets do? Every application is different — and so every combination of widgets used brings a new set of challenges. This is how we make progress and is how the current features of frameworks came into being — by experimentation and pattern discovery.
The web application framework itself is relevant because it enables developers to write solid software by reusing common components. Common patterns used in all web applications. Without these tools supplied by the framework, nothing would ever get off the ground — a diffuse time to market for smaller development teams.
What patterns are used in web frameworks? Database connectivity, URL mapping, authentication. The list goes on, each framework providing their own flavor of these major components. Each is considered a pattern because any web application needs to implement it. This quickly burdens the developer. The role of a web framework is to parameterize these patterns and make them accessible.
What role do widgets play in web application frameworks? By widgets, I mean standalone Javascript toolkits that have a selection of cool user interface stuff. This includes jQuery UI, Dojo, and ExtJS. Making these Javascript widget tool kits — which are a framework on their own — integrate seamlessly into our web application frameworks is disjointed to say the least.
Not an easy fit
Web application frameworks don't give us all the front-end browser code necessary for a finished product. If it were a matter of delivering only HTML and CSS to the browser, we'd be all set. This isn't the case unfortunately. Not if there is any kind of user interaction involved — which is almost certainly the case. For the kind of experiences users have come to expect, developers need to employ Javascript or Flash technologies.
In theory, building these rich user experiences is fairly straightforward — alter the HTML templates and serve the additional resources — Javascript, Flash, etc. This can be achieved without any headaches — granted the project is a small one. There many resources to worry about, not as big a user base compared to something enterprise-grade. Every aspect of the software is scaled back slightly — and so the cause for error is scaled back accordingly. For example, having a very large Javascript file or dozens of smaller Javascript files can be hard to maintain. Not on their own — but because Javascript is different — it depends heavily on the DOM.
So as far as the development process goes, we need sound approach to ensuring there is some degree of coupling between individual HTML templates and their corresponding Javascript modules. The days of implementing a monolithic Javascript file are quickly leaving us behind. Especially if given the challenges of managing external widget library dependencies. Imagine an application with a hundred or more HTML templates — I can't think of an optimal method where a single Javascript module suffices.
Technically speaking, uniting widget frameworks and web application frameworks wouldn't be overly strenuous. All this entails, and this is generally how they're put together now, is serving new resources and having your HTML content ask for those resources. The place where widgets don't fit seamlessly into the web application framework is in the back-end the web application. How does a given view or controller (whatever the framework terminology alludes) know about which widgets are used? Are these widget configurations persistent? For that matter, are they configurable at all from the web framework? For me this is a problem — widgets are a big part of the overall picture — web application frameworks should accommodate widget frameworks.
Frameworks and forms
A crucial feature of any software with a web user interface is forms. Forms collect user feedback. They can be simple — a single input field and a submit button. They can be complex — a registration form that nobody in their right mind would fill out. Web application frameworks do a pretty good job with tools that both render and validate forms.
There is good reason for. Web frameworks define the database schema for the application. The database is populated by user input. Forms. There is an obvious connection between the two concepts — this is why frameworks take great care to supply the database with what it expects.
Take Django
for example. The Django framework has a forms module that'll assist with defining forms, the validation, and rendering the form widgets for the browser. Not unlike how Flask uses WTForms to validate and present forms. The Pylons project also provides developers with form processing capabilities — they require a little more effort than the other Python frameworks.What really stands out is the connection forms and their individual input widgets have the framework itself. They're an essential ingredient to the application — a formative piece of the database. There is a mapping between the database schema and what is presented to the end user so they can populate it. This fits perfectly with the ideal of the web application framework — to take a pattern and expose it as a cohesive API for the developer. This concept is further exemplified by Django where we're able to point the form subsystem to a database model and let it figure out how the form should be rendered and validated. This isn't so easy with more general widgets that aren't necessarily used for collecting input and storing it.
Widgets and data
If we're able to utilize the framework form processing tools to store data, how does the framework help us present data to the user? Well, since a web application framework is only responsible for delivering the content to be rendered by the browser, all we've got is templates. These assist in generating the markup necessary for displaying fancy Javascript widgets.
For instance, a common user interface pattern is to group logical categories using tabs. Tabs are visually appealing and allow for intuitive navigation. This is a top-level layout widget — meant to replace a typical sidebar navigation item. Or consider a smaller widget — a progress bar. This type of widget, unlike tabs, isn't a layout container. It displays something specific about the application data.
What both layout container widgets and smaller application data widgets have in common is that they both depend on specific application details that reside on the server, within the framework. The tabs widget needs to know what specific tabs to display and what content within each tab. The progress bar widget probably depends on a computed number — derived from user data from the database. So what is the preferred approach to displaying both widget types in any given application?
Navigational constructs are typically done in the template. Maybe there is a nested div and a tag structure the Javascript widget is expecting — like the jQuery UI tabs widget. However, the developer still needs to instantiate their widget when the page loads. This means that the Javascript code needs to know about the template and what the rendered HTML output will look like. This is somewhat error-prone as the developer will need to maintain dependencies between the Javascript widgets and the HTML structure they're expecting.
More challenging is the application user data presented by widgets — like a progress bar. The progress bar needs the value to display — but where does it come from? This might be a JSON response, returned from one of the application controllers. Again, as with defining layout widgets, the problem lies in maintaining the connection between what the Javascript widget is expecting to see and what the framework delivers. The problem isn't so much technical — it is more of a design problem. One that leads to a loosely coupled system. Too loose.
Solutions and challenges
Web frameworks already do a great job of taking common patterns on the server and making tools developers can use to efficiently develop code. Might it be that web application frameworks have no business managing widgets? Should this task be left to the templates and other static files? I think there are patterns we're missing here that can be taken advantage of — it's still only an emergent thought.
One benefit to having the framework manage the connection between application data and widgets is the potential to be widget framework agnostic. There are a lot of widget tool kits out there and a lot of similarities between them. The commonalities across all toolkits — these are the interesting widgets. The basic widgets that all web applications use in one form or another could potentially be integrated into web frameworks.
What might we do with the layout widgets to help standardize and improve the coupling between Javascript and framework data? After all, layouts, if they can be standardized in some fashion, are a valuable asset. You'll generally have a web application framework of choice and you'll almost certainly be creating more than one application.
I think layout widgets — stuff specific to the user interface and not necessarily what the application does — will be easier for frameworks to implement. If the framework is able to introduce the concept of a widget, maybe storing it's configuration, then properly outputting the required markup and the required Javascript isn't a stretch. For example, the configuration for a tabs widget would store what tabs are actually rendered, the contents of each tab, and should produce the necessary Javascript to instantiate it.
Widgets specific to application data — like a grid — aren't as easy. This is because they're more toward what the application does. Another challenge is that widgets generally depend on some data source like JSON that is generated from the user data. This isn't so easy to stardardize on. The framework would have to know about the data schema in addition to the visual configuration. This means the application would have to store configuration that dictates what the widget will look like, where to get the data it needs, and how that data should be interpreted for presentation. Not impossible, just more challenging.
Perhaps a good start to making web application frameworks a little more aware of patterns in how browser widgets interact with the framework itself is to discover patterns you're using. How would you benefit if you're able to store some configuration that defines how and what the Javascript widgets do? Every application is different — and so every combination of widgets used brings a new set of challenges. This is how we make progress and is how the current features of frameworks came into being — by experimentation and pattern discovery.
Wednesday, June 29, 2011
There's A Web Page For that
Yep, there's a web page for that, a ton of them. The one thing you need, a currency calculator, a CSS generator, there are probably five different web pages fit for the job. How useful are these web pages on mobile devices? It seems that applications native to the mobile hardware replace the browser entirely. These apps don't work everywhere - you don't see the same code running on iPad, Android, and BlackBerry. Each application that runs on a phone, if you can still get away with calling it a phone, is tailored to the hardware. Is this really a big deal to the user? Is the device-specific experience really that much better than something running in the browser? Currently, yes. Web stuff for mobile doesn't quite make the grade comparatively. No, there isn't always a mobile web page for that. But there will be.
What are web pages for? Information, of course. Well, I'd say the vast majority of web pages are about sending a message to an audience. However, plenty of web sites are currently transforming their content - or at least thinking about it - into something that's more like the desktop application experience. This is what users want, and so us software creators must have a pretty good reason to not deliver.
Why the change? Our websites never used to have trouble engaging with users. Why all the fuss over user admonition? The short answer is because we can. If a company selling widgets has an opportunity to hear the assessments of current and prospective customers, they'll take it. In fact, they're going to encourage users to submit any feedback. There is no such thing as a customer giving bad information to a company about their product. I mean, yes, there will be the odd loudmouth who does nothing but criticize, but this is nothing new. We've got to deal with those types even if we don't operate on the web.
We've got a bidirectional channel for businesses – much more effective than television. Rather than pushing out information, hoping people are watching, it's always available your clients seek it. If you want immediate feedback, provide your consumers with the appropriate tools.
Applications that don't utilize the web as a data repository aren't modern in any sense. We need applications that access the web, otherwise, users can't provide their feedback. We'd be crazy not to, right? If an online store, selling say, music, isn't hearing about each customer's unique experience, why might that be? Maybe they simply don't feel enticed to respond, probably because it takes more effort than it's worth. The question is, how to we make these feedback tools seamless to the point of being irresistible to the viewer? This is interesting to think about, especially in a mobile context where things suddenly aren't so straightforward.
Web pages aren't universal. Not anymore. We're really good at building just about any kind of application for the web, just as long as you build it for desktop and laptop browsers. Even some tablets do a decent enough job of displaying your retro backwardness that is 1.0. The rest of your users don't have the luxury of a larger display. To them, viewing pages on your site is like trying to plot a route on a map while looking through a magnifying glass pressed against it. It's a little unpleasant.
How do these web pages become a little more tolerable for the mobile audience? After all, we want to capture everything they're willing to tell us – we've got to make this as simple as possible. The answer in the mobile domain is apps. Users love their devices, and filling them with software amends their utility. What good is a smart phone without hundreds of applications installed? It isn't actually easier for users to interact with your mobile application, relative to your mobile web page that does the same thing. The application, once installed, feels like part of the device. That might seem too obvious, all software controls the hardware. This is no different from software installed on our desktop computers – new software extends the capabilities of the hardware. And since its installed locally, we've just expanded the capability of our hardware. There is something about the intuitiveness of desktop software. This is where mobile applications have an edge – they truly become one with the device for which they're built.
Why can't web applications do the same? Why can't they mesh well with the hardware they're delivered to? They can, and do. The trouble is that there simply isn't enough of them. There is a strong argument for developers to build web user interfaces for mobile users. Its the same argument for building web applications for desktop users – supporting several platforms is a major headache. Supporting multiple desktop platforms and multiple mobile platforms is simply out of the question for most folks. We've got to overcome the obstacle of unfamiliarity. Users want to install things, they want a level of assurance, knowing the tool will reliably get the job done.
The question is, can we give users this same level of comfort, the intuitive feeling that the web user interface is somehow part of the device. I think so. As long as they're able to launch it as they would any other native application. A little icon, part of a start-up menu, whatever the environment dictates, it just needs to mesh well.
Over time, I'd say over the next few years, we'll see web user interfaces become the standard. Apps won't go away entirely, there will always be a need for something specialized that no browser can support. However, the roles will shift – the browser will become the default user interface environment, desktop software the fallback. So yes, it's important that users feel comfortable using their software no matter the device. Software that's intuitive always comes out on top. As little as five years ago, web applications for the desktop weren't anywhere close to native desktop applications. All that's changed now – there is still a need for specialized desktop applications, but browser-based user interfaces are the first choice for a lot of developers now. I think this same transformation will happen with the mobile market sooner rather than later.
Thursday, April 1, 2010
Wednesday, March 17, 2010
Simple Zope HTTP Server
I've seen mention of every conceivable Python web framework as of late. Mostly performance comparisons. One I don't see that often is Zope. It is a mature framework that does everything under the sun. I think it isn't mentioned that often by developers because of the lack of documentation.
The good news is that Zope code is easy to read and understand. I decided to experiment and create a really simple HTTP server with Zope HTTPServer. I find the task-oriented view of each HTTP request both interesting and useful. Here is what I came up with:
import asyncore
from zope.server.http.httpserver import HTTPServer
from zope.server.http.httptask import HTTPTask
from zope.server.taskthreads import ThreadedTaskDispatcher
class MyServer(HTTPServer):
def executeRequest(self, task):
task.start()
self.log_info("Starting request task.")
task.response_headers['Content-Type'] = 'text/plain'
task.response_headers['Content-Length'] = 5
task.write(task.request_data.command)
task.write(" ")
task.write(task.request_data.uri)
task.finish()
self.log_info("Rquest task finished.")
if __name__ == "__main__":
dispatcher = ThreadedTaskDispatcher()
dispatcher.setThreadCount(10)
MyServer('', 8084, task_dispatcher = dispatcher)
try:
while True:
asyncore.poll(5)
except KeyboardInterrupt:
dispatcher.shutdown()
Monday, March 8, 2010
HTML5 Storage Complexity
With new emerging HTML5 standard, Google is focusing on using the standard for local, client-based data storage. Its nice to have some flexibility in the browser in terms of how data is stored and how to go about retrieving that data. Having a database API would no doubt help in that effort.
But is that getting too complex? Having a feature-rich data store in the web browser might take too much of the design focus away from the overall service architecture. Instead, I think it makes more sense to store URIs on the client. These URIs represent the potentially complex resource states that live on the server.
But is that getting too complex? Having a feature-rich data store in the web browser might take too much of the design focus away from the overall service architecture. Instead, I think it makes more sense to store URIs on the client. These URIs represent the potentially complex resource states that live on the server.
Thursday, December 10, 2009
The New Javascript
It appears that the ECMA organization has approved the new ECMAScript 5, otherwise known as javascript, standard. It has been ten years since an adopted change to the standard has been made. However, this hasn't stopped web applications from evolving to something that resembles the desktop more and more with each passing year.
The ECMA plans to submit the newly adopted javascript standard as an ISO standard. I think this would be a very good move, especially if web browser vendors decide to stick to the standard.
Aside from the javascript standardization front, there have also been some new features introduced. For instance, javascript objects, or JSON objects, will be able to operate in an immutable mode if chosen to do so. This is could prove useful for working with javascript objects that are returned from an API and aren't intended to be manipulated. Also, the javascript interpreter itself will be able to operate in a strict more that is less forgiving toward malformed-syntax. This will be a blessing for developers that don't feel at ease with deployed javascript that may or may not be well-formed; it may or may not work in some browsers.
The ECMA plans to submit the newly adopted javascript standard as an ISO standard. I think this would be a very good move, especially if web browser vendors decide to stick to the standard.
Aside from the javascript standardization front, there have also been some new features introduced. For instance, javascript objects, or JSON objects, will be able to operate in an immutable mode if chosen to do so. This is could prove useful for working with javascript objects that are returned from an API and aren't intended to be manipulated. Also, the javascript interpreter itself will be able to operate in a strict more that is less forgiving toward malformed-syntax. This will be a blessing for developers that don't feel at ease with deployed javascript that may or may not be well-formed; it may or may not work in some browsers.
Wednesday, December 9, 2009
Chrome OS
There is a lot of hype around the new Google Chrome OS as of late as the source code has been released. There should be lots of hype around this new operating system because it is a new concept. Sure, there are net-books you can use for your light-weight web browsing purposes. But that doesn't really cut it if you have stuff to do.
The approach behind the Chrome OS is that it is a web browser that grew up into a light-weight operating system. The OS isn't concerned with running local desktop applications and can optimize for the web. I find this concept both interesting and frightening.
The idea of having a computer that I cannot use, in the conventional sense will most likely turn many people off. It is a little scary that none of your data is in your hands. With a conventional laptop, you can at least store whatever you want and carry it around with you. I wonder what Google will do if people don't like that idea of all their data being out of their hands. Not likely to happen.
The approach behind the Chrome OS is that it is a web browser that grew up into a light-weight operating system. The OS isn't concerned with running local desktop applications and can optimize for the web. I find this concept both interesting and frightening.
The idea of having a computer that I cannot use, in the conventional sense will most likely turn many people off. It is a little scary that none of your data is in your hands. With a conventional laptop, you can at least store whatever you want and carry it around with you. I wonder what Google will do if people don't like that idea of all their data being out of their hands. Not likely to happen.
Wednesday, October 7, 2009
Twisted Sevices
Twisted is one of the more mature Python networking libraries in existence. It has been around for over half a decade and has a very feature-rich code-base. There are several sever types that can be implemented with Twisted. This is actually a real requirement for many applications. For instance, an web application will obviously need an HTTP server for the web front-end. That same application may also want to provide a lower-level server for an API that generates less overhead. However, having to write something custom just to ensure that these servers are started along with the application seems a bit much. Especially if the servers are both a Twisted implementation. Luckily, Twisted has just the solution for this scenario.
Twisted provides developers with a MultiService class that is used to create multiple network service that behave logically as one server. Server implementations in Twisted can set the parent service to be an instance of MultiService. This MultiService instance can then be started with multiple child servers.
However, one last step should be taken. In order to make your service work with the twistd command, that is make it a sub-command, you must make the service properly. This is done by implementing a class that implements the IServiceMaker interface. This same class should also implement the IPlugin interface since it is a Twisted plugin in addition to a service.
The IServiceMaker interface requires attributes that dictate the name of the sub-command used with twistd. Also, command parameters and a description are part of the interface and should be provided.
This is a really nice way for an application to manage multiple services provided by the same application. It also goes to show that Twisted's experience is also reflected in the API.
Twisted provides developers with a MultiService class that is used to create multiple network service that behave logically as one server. Server implementations in Twisted can set the parent service to be an instance of MultiService. This MultiService instance can then be started with multiple child servers.
However, one last step should be taken. In order to make your service work with the twistd command, that is make it a sub-command, you must make the service properly. This is done by implementing a class that implements the IServiceMaker interface. This same class should also implement the IPlugin interface since it is a Twisted plugin in addition to a service.
The IServiceMaker interface requires attributes that dictate the name of the sub-command used with twistd. Also, command parameters and a description are part of the interface and should be provided.
This is a really nice way for an application to manage multiple services provided by the same application. It also goes to show that Twisted's experience is also reflected in the API.
Sunday, September 20, 2009
HTTP Response Schema
The HTTP protocol is by far the most prominent protocol on the web today. Most people browsing the web aren't even aware of its existence. They just see a strange "http://" string in front of where they want to go. The great part is that most users of the web don't need to know what HTTP is or how it works. The browser and the web server have a firm understanding of how to use the protocol.
Web clients, including the browser need to understand how to handle HTTP responses. Contained within each HTTP response is a numeric code indicating the status of the request. Although HTTP is a stateless protocol, the client needs to know what happened with each request made to the server. One may consider the response code to be a meta state. The response code can still support statelessness on the server.
Each HTTP response code has a distinct explanation for why the requested responded the way it did. The client can also interpret a more general category, or nature of the response because of the ranges in which each specific code falls under. Here is a brief idea of what the ranges mean:
• 200 - Success.
• 300 - Client action required.
• 400 - Client error.
• 500 - Server error.
In an object-oriented design, these ranges of HTTP response codes can be broadly generalized. This helps to conceptualize how the client can handle several specific response codes in the same way as is illustrated below.
Web clients, including the browser need to understand how to handle HTTP responses. Contained within each HTTP response is a numeric code indicating the status of the request. Although HTTP is a stateless protocol, the client needs to know what happened with each request made to the server. One may consider the response code to be a meta state. The response code can still support statelessness on the server.
Each HTTP response code has a distinct explanation for why the requested responded the way it did. The client can also interpret a more general category, or nature of the response because of the ranges in which each specific code falls under. Here is a brief idea of what the ranges mean:
• 200 - Success.
• 300 - Client action required.
• 400 - Client error.
• 500 - Server error.
In an object-oriented design, these ranges of HTTP response codes can be broadly generalized. This helps to conceptualize how the client can handle several specific response codes in the same way as is illustrated below.
Friday, September 18, 2009
Syntax Highlighting
A lot of code these days in a variety of languages is posted on the web. I myself like to post small snippets of code every now and then. The pre HTML element was intended for just such a purpose. The content of these elements looks like code. Or, something that is code-like. However, the pre element poses a simple drawback; the code is still difficult to read in most cases. That's not to say that placing programming language code in a pre as opposed to somewhere mangled within the plain text is a bad thing, it is simply a matter of interpreting the code faster. Trying to read code that has not been highlighted to reflect the language in which the code was written is a challenge to say the least. With every programming language, there are several key tokens that carry more meaning than others when read by a human. For instance, in most object-oriented languages, the class keyword is going to stand out. Except, with code that is displayed on the web, it doesn't. At least not at first if the code isn't syntax-highlighted.
Spoken languages such as English don't really need the assistance of a syntax highlighter to emphasize various token types because humans either understand it, or they don't. There is quite a difference between what a computer is able to interpret and what a human is able to interpret. Hence the rigiditety of programming languages in comparison to spoken languages.
With programming language code that is displayed on the web, there is a simple need for that code to be displayed as if it were being displayed in an editor that supports syntax-highlighting. Even though the code isn't editable, that isn't the reason syntax-highlighting is built into code editors. It exists for reading purposes. It would probably be more productive to copy the code from the web and paste it into an editor that will highlight the syntax than it would be to try to read the code that is not highlighted.
This is where the Pygments Python package comes into play. Pygments is a very feature-rich syntax-highlighting application and API. Trac, which depends heavily on the need to display code on the web, is a perfect use case for Pygments and its' API. The application part of Pygments is a simple command line utility which is perfect for highlighting smaller snippets of code.
Spoken languages such as English don't really need the assistance of a syntax highlighter to emphasize various token types because humans either understand it, or they don't. There is quite a difference between what a computer is able to interpret and what a human is able to interpret. Hence the rigiditety of programming languages in comparison to spoken languages.
With programming language code that is displayed on the web, there is a simple need for that code to be displayed as if it were being displayed in an editor that supports syntax-highlighting. Even though the code isn't editable, that isn't the reason syntax-highlighting is built into code editors. It exists for reading purposes. It would probably be more productive to copy the code from the web and paste it into an editor that will highlight the syntax than it would be to try to read the code that is not highlighted.
This is where the Pygments Python package comes into play. Pygments is a very feature-rich syntax-highlighting application and API. Trac, which depends heavily on the need to display code on the web, is a perfect use case for Pygments and its' API. The application part of Pygments is a simple command line utility which is perfect for highlighting smaller snippets of code.
Monday, April 27, 2009
Python BaseHTTPRequestHandler Request Parsing
When a client sends an HTTP request to a server, that request is sent as a raw string of HTTP request data. Each component of the HTTP request, while in the transit state, is still considered a single monolithic component. This raw HTTP request must be parsed. It is the parsing action that transforms this raw HTTP request string into a coherent set of HTTP request components. Python provides a module in the standard distribution that provides basic HTTP request parsing capabilities. The class used for this is called BaseHTTPRequestHandler. As the name suggests, it is the most basic of all HTTP request handling capabilities provided by Python and must be sub-classed to carry-out any meaningful functionality. What we are interested in here isn't such much the extending of the BaseHTTPRequestHandler class as much as how the HTTP request parsing of the class is broken down. This fundamental action of web programming in Python is rarely seen because many web application frameworks do this for us. Even when using the fundamental BaseHTTPRequestHandler class, developers need not concern themselves with parsing individual HTTP requests. This is also taken care of by the class as a step in the request handling activity. It is useful, however, to see how the most fundamental HTTP request parsing functionality works and if there are any weaknesses with the approach.
The following is an illustration of how an HTTP request is parsed by the BaseHTTPRequestHandler class. Keep in mind, this is only a high-level view of what actually happens. There are many smaller steps kept out of the illustration for simplicity.
One question to ask here is if any of these actions can be parallelized. One candidate might be the initialization of the HTTP headers. The reason being, there is no prerequisite input to the header initialization that isn't available before the actions previous to the header initialization are executed. Suppose this action were carried out in a new thread, would there really be any significant performance gain. Unlikely. Is it an alternative design worth exploring? I would think so. See below for an illustration of the header initialization executing in parallel with the other HTTP parsing actions.
The following is an illustration of how an HTTP request is parsed by the BaseHTTPRequestHandler class. Keep in mind, this is only a high-level view of what actually happens. There are many smaller steps kept out of the illustration for simplicity.
One question to ask here is if any of these actions can be parallelized. One candidate might be the initialization of the HTTP headers. The reason being, there is no prerequisite input to the header initialization that isn't available before the actions previous to the header initialization are executed. Suppose this action were carried out in a new thread, would there really be any significant performance gain. Unlikely. Is it an alternative design worth exploring? I would think so. See below for an illustration of the header initialization executing in parallel with the other HTTP parsing actions.
Tuesday, February 3, 2009
Web-based applications a good idea?
An entry on infoworld doesn't think so. Apparently the web browser sucks for applications and anyone using them are reverting back to the client server model. Well, it is a client (the browser) and it is a server (whatever). The strong case for the web application in the browser is deployment. There is no easier way to distribute a GUI than the web browser. Unless that is, everyone in the world used Windows.
Of course, the case against the browser is strong too. The same interoperability problems that operating systems experience are shared in the browser domain. In short, your HTML/CSS/AJAX GUI may not work across all platforms (platforms being web browsers in this case).
In terms of GUI interoperability and deployment, the same problems persist. There is no easy way to make everyone happy. And that will always be the case as long as people use different operating systems. There exists no simple unifying solution. Again, with web browsers, you have the interoperability problem. With interpreted languages, it is quite simple to achieve interoperability amongst various operating systems. I think the problem there is deployment. It is a lot tougher to deploy desktop applications that use any kind of data center.
The main problem I see with the suggested solution in the infoworld entry is that there is no mention of distributed data. Lets say I take the advice from the entry and all our customers now use our new Java desktop application. Where did the data go? Any modern requirements will scream distributed data. And that is another complexity there is no alternative for.
All these challenges, distributed computing, distributed deployment, and interoperability, they have been around for a while now. I agree with the author in that for the most part, web browsers suck for any kind of reliable user interactivity. However, I still don't see any solutions over the immediate horizon that will make the browser go away.
Of course, the case against the browser is strong too. The same interoperability problems that operating systems experience are shared in the browser domain. In short, your HTML/CSS/AJAX GUI may not work across all platforms (platforms being web browsers in this case).
In terms of GUI interoperability and deployment, the same problems persist. There is no easy way to make everyone happy. And that will always be the case as long as people use different operating systems. There exists no simple unifying solution. Again, with web browsers, you have the interoperability problem. With interpreted languages, it is quite simple to achieve interoperability amongst various operating systems. I think the problem there is deployment. It is a lot tougher to deploy desktop applications that use any kind of data center.
The main problem I see with the suggested solution in the infoworld entry is that there is no mention of distributed data. Lets say I take the advice from the entry and all our customers now use our new Java desktop application. Where did the data go? Any modern requirements will scream distributed data. And that is another complexity there is no alternative for.
All these challenges, distributed computing, distributed deployment, and interoperability, they have been around for a while now. I agree with the author in that for the most part, web browsers suck for any kind of reliable user interactivity. However, I still don't see any solutions over the immediate horizon that will make the browser go away.
Subscribe to:
Posts
(
Atom
)