- We design and build extraordinary applications for companies looking to make the next great idea a reality.
- learn more
How to Tell the Difference Between a Web Site and an Application
The World Wide Web is not just for informational, or marketing based web sites anymore. These days it’s hard not to run into web sites that behave more like the applications you are used to seeing on your desktop--dynamic, super-responsive, transactional, task based, tool oriented. And as the web becomes more saturated with destinations that offer app-like functionality, the line between web sites and applications are blurring. It’s become increasingly difficult to tell the difference between those web site that are simply sites, and those that are really applications in web site clothing.
It may very well be that distinguishing between the two is an outdated concept, relying on an arbitrary line in the sand. But that doesn’t mean I can’t take my best shot at listing some of the things that web applications have in common, so that I can draw a more clear line separating them from their ancestors. If a web site has 10 or more of these, I would call it a web app:
It requires users to Log in.
It requires user input (i.e. filling out forms)
It performs tasks, rather than just providing information
It remembers you
It is dynamic (That is, it doesn’t need a page refresh to respond to user input)
It communicates to other software (such as a calendar sending email or text
messages)
It allows users to save information to a web server
It saves information on the users hard drive
It contains drag and drop functionality
It doesn’t contain ads, and…
It costs money to use
It contains more buttons than links
It contains more drop down menus than images
It contains no links to outside websites
It is secure (it uses HTTPS to send and receive information)
It isn’t real pretty
It frequently displays alert messages
Creating an Experience
Interface Designers don’t just design software GUI’s, we design experiences. It is job number One to keep this in mind. We have to understand that experiences are the sum total of all of the circumstances that combine in one moment for one person. The satisfaction a user receives when they work on a well designed piece of software comes from many factors, some of which we cannot control. But the more we uncover and internalize about the circumstances that together produce an experience, the better chance we have of designing software that makes a satisfying one.
This is no less true of Visual Design, when we typically apply the polish that will hopefully add to the user’s experience in a positive way. It might be easier to think of Visual Design as a separate part of the project, distinct from Requirements Gathering and Information Architecture, and in many ways it is. It’s certainly useful for budgeting and project planning. But that type of thinking can go too far, and lead to arbitrary compartmentalization of a project. Since the goal is a product that provides its users with a satisfactory experience, that experience has to be uncovered trough extensive research—and more than a little common sense—and then shared and indeed owned by all those involved in designing that experience.
The absence of this shared goal in Interface Design is a disjointed and ultimately unsatisfying experience, no matter how well any of the individual parts work. And unfortunately it is all too common. It can be seen when a User Interface looks sleek and sophisticated, but works like a lemon; or when it works fantastically, but looks so ugly that it gives its users a headache.
If however, that shared goal in software design is understood clearly and internalized in everyone’s work, then it is much more likely that the user will intuitively feel it, and come away with a better experience.
Adobe CS 3 Just Released
Adobe released its 2007 product suite this past week. As soon as I heard the news I jumped onto the website (adobe.com) to get a glimpse of some of the new product enhancements featured in this new release, dubbed CS 3.
Although I’ve used all of Adobe’s big ticket products at some point in my career as a designer (and I hope to one day be professionally reintroduced to After Effects), on the job I work primarily in Photoshop Illustrator Flash and GoLive. So I set off to get a look at what is in store for the CS 3 version of these tools.
My first destination was to Photoshop, where I got a glimpse at some interesting new features. The most striking of them being the new tables interface (which I can’t judge because I haven’t used it yet) and the radically enhanced selection toolset, which, judging from the online demo seems almost spooky in its intelligence and it’s uncanny ability to recognize objects in images the way we do.
Next, I visited the Illustrator page. I was really impressed with the new features in this release, especially since Adobe has a history in recent years of productizing minor enhancements to illustrator so it can keep up with its big brother.
The most impressive feature in any one of the products I reviewed is Illustrators new Live Color tool. This revolutionary tool lets you adjust color across your entire canvas by selecting groups of colors and moving them synchronously across the color palette, maintaining relative relationships between each of the colors. Updates are viewable in real time on the canvas as you drag your change your colors. Job well done, Adobe.
Flash CS 3 looks like it received the most extensive makeover, and this comes as no surprise, given it’s popularity as a web development tool, and this being the first chance Adobe could get it’s hands on it. The most expected, and most beneficial enhancements are to Flash’s integration with the other adobe products, specifically Illustrator and Photoshop. You can now import both AI and PSD files directly into Flash while preserving layers and structure.. Other enhancements include enhancements to Actionscript 3.0 as well as the ability to save and reuse animations, just like symbols.
I don’t use Dreamweaver currently, having found my mojo in GoLive. However I will be making the switch eventually, Adobe has made sure of that. They’ve discontinued the GoLive line in favor of the more popular Dreamweaver, which they inherited along with Flash when they bough Macromedia last year.
Adobe has enhanced Dreamweaver’s support for CSS based web page creation in this release. Included with the product is a set of CSS layout templates from which you can start building pages. Also new are the CSS managements tools which allow you to, among other things, quickly move styles between documents and between inline and external style sheets.
Dreamweaver also comes with support for Adobe’s Spry framework, which is a set of components that use Ajax and other dynamic clients side techniques to allow web designers to more easily build rich web sites.
Topics: Design
My Mash Note to Microsoft, Newest Member of the OpenAjax Alliance
It is easy to be cynical about Microsoft's recent entry into the OpenAjax Alliance. After all, the alliance is mostly a marketing vehicle for it's members. The "technology" portion of the OpenAjax Alliance revolves mostly around things like playing namespace cop -- more problems of the Javascript language and browser platform than real framework issues -- and is making very modest progress. Beyond the bitching of the odd developer about Prototype not playing nice with other frameworks, the real problem with Ajax frameworks is that they each reinvent the wheel, not that they don't work well together. This sort of ad-hoc interoperability -- making sure that different libraries and frameworks don't clobber one another -- reminds one of the legislative process: when the parties are divided, a weak compromise is often the best for which you can hope. (See John Reisig's take on why the OpenAjax Hub is in fact not a very good technical solution.)
Not that these efforts are useless; they are better than nothing. But both Ajax and the browser platform are still moving targets. Investing heavily in a standard that may evaporate once the next version of the browser comes out or if Ajax development moves away from direct browser programming to more abstracted models (Echo2, GWT, etc.), seems like something you would want to do quite slowly.
So, is Microsoft's entry a sign that it really wants to play nice, or is this part of its diabolical plan to "embrace, extend and extinguish?" I think the answer is more the former than the latter, and that has me feeling all warm and fuzzy towards my blue badge buddies in Redmond. I think Microsoft, by getting rid of its annoying compatibility layer, is trying to embrace open source Ajax libraries. Why? Because they realize that writing fancy eye-candy DHTML/Ajax wizardry is hard and expensive. Much better to treat this little browser ecosystem the way they treat custom WinForm controls -- a marketplace too fragmented for MS to efficiently play, but whose vitality and diversity needs to be encouraged in order to add value to the base platform, .NET in both cases.
I think this apparent willingness to foster third-party Ajax libraries is the real news, not their entry into a very corporate ("Member of the OpenAjax Alliance"), very marketing oriented, marginally technically useful organization.
Topics: Ajax Components, Ajax Frameworks, Ajax Widgets, Editorial
5 Practical Uses for Web Animation
Most animation being served up on the web serves no purpose other than to distract, irritate, annoy or confuse. Most web interface designers would tell you, rightly so, that as a general rule, it’s better to stay away from animation. But there are certain instances where animation would actually provide valuable utility. Here are Five.
To Indicate Progress
Progress bars might be the most ubiquitous use of practical animation on the web today. There’s no better way to indicate how far a process has come and how much there is to go than to include one of these simple UI elements on screen. The key to it’s effectiveness is that its real time, which is the direct result of the animation.
To Alert
At certain points it becomes imperative that an interface spotlight a position on screen and direct the user’s concentration there. Taking advantage of human instinct by using motion to grab the user’s attention, a well designed animation will do just that,
To Indicate Hiding / Revealing Items
In addition to providing a nice polish to an otherwise binary operation, animated show hide items provide important information—because motion is involved in hiding an item, they let the user know where to access an item that is currently hidden.
To Convey Statelessness
Through over a decade of conditioning, web users expect sites to behave according to the page model, in which each new display represents a new page load. However, in an Ajax/Flash/DHTML world, it’s important that rich interactions, which by definition do not conform to the page model, be clearly illustrated as such, so that users know what to expect when they hit the back button. Animating between display states is a great way to achieve this, because it unambiguously lets the user know that no new page has loaded.
To Illustrate Complex Tasks
Sometimes Two or even Three dimensions are not enough to convey all the information that needs to be conveyed. In those cases an animated illustration can do the trick.
Topics: Interaction Design
Do you know your SiteKey?
SiteKey is a system some sites (notably banking sites) use to prevent customers from logging into fraudulent sites dummied up to look like the actual sites. During registration (or updating an account if it was created pre-SiteKey), the user is asked to select an image they would like to associate with their account. Thereafter, the SiteKey image is displayed when the user logs into the site, reassuring them that they’re logging into the actual site. In theory, displaying the image instills trust and confidence in the user.
The reality, according to a joint study conducted by Harvard and M.I.T., is that users tended to enter their password regardless of whether or not the image is displayed. Only a few refused to enter their password citing security concerns. Not good.
Now, keep in mind that the test was done in a controlled environment with the users being asked to conduct routine online banking activities. They may have felt secure in their surroundings (an official test, Harvard, M.I.T., etc.), and it may not have bothered them to find no image being displayed (if they even noticed). Plus, typing the url directly into the browser vs. clicking a link from an email generates different levels of security which may have caused them to go directly to the input boxes for login.
But perhaps the images (or lack thereof) were ignored for other reasons. For those of us who only rarely login to SiteKey sites, it’s next to impossible to remember the image that we’ve selected. Face it, I can barely remember my passwords. So even if I see an image, I have no level of assurance that the site is legitimate since my recollection of whether or not the proper image is being displayed is spotty at best.
However, there is one exception -- a site that allowed me to upload my own image and associate it with my account. Because I could use an image that is meaningful to me, the SiteKey implementation thereby became a much more effective tool in alerting me to the site's legitimacy. Amazing how things improve once you involve the user.
Adobe Apollo - First Impressions
I just worked my way through the O'Reilly Apollo for Adobe Flex Developers Pocket Guide. This booklet is written by the Apollo development team and is essentially a "getting started" guide to the Alpha1 release. The booklet doesn't contain anything that you can't find in the online documentation available from Adobe (which may in fact be more up-to-date), though. In fact, they both contain the same oversite, i.e. they neglect to mention that you will need some sort of Flex SDK for the Apollo SDK to work. That may seem obvious, but is in fact a bit of a stumbling block for those of us expecting the Apollo SDK to be a complete solution. For those of you looking to experiment with the SDK, download the free Flex SDK and unzip it to the same dir where you plan to install the Apollo SDK.
What is Apollo?
It is important to step back for a second and point out what Apollo is not. Apollo is not a general desktop runtime meant to compete with lower-level application runtimes. This means that you probably wouldn't want to build Photoshop on top of Apollo. Apollo's primary use case is enabling Rich Internet and web applications to be deployed to the desktop. This is a very important but subtle distinction, as enabling RIAs on the desktop is the primary use case driving the Apollo 1.0 feature set.
[...]
Apollo solves most of the problems with deploying web applications via the browser. However, there are still advantages to deploying applications via the browser. The fact that there are so many web applications despite the disadvantages discussed earlier is a testament to the advantages of running within the browser. When those advantages outweigh the disadvantages, developers will still deploy their applications via the web browser.
But is it not necessarily an either/or question. Because Apollo applications are built using web technologies, the application that you deploy via the web browser can be quickly turned into an Apollo application. You can have a web-based version that provides the browser-based functionality, and then also have an Apollo-based version that takes advantage of running on the desktop. Both versions could leverage the same technologies, languages, and code base.
Apollo applications complement web applications. They do not replace them.
I have been and continue to be skeptical about the future of Apollo. The niche described above seems most compelling for the mobile space, support for which is not in Alpha 1. You think Apollo is going to take off? Then I have a Java WebStart app I'd like to sell you.
What else is in Alpha 1? Support for Flash (surprise), HTML and tight integration between the Flash/ActionScript and Javascript/DOM sides of the house, abstraction of OS services (File I/O, windows, etc.). What isn't in Alpha 1? No PDF support, nor the talked about security or offline parts of the platform. They need to introduce this kind of support quickly, otherwise nimble desktop RoR beasts likeSlingshot that promise to have "simple and transparent data synchronization" will eat their lunch.
As for developing applications in it, if you've developed Flex apps before, it should all seem very familiar, with the addition of some OS/Browser specific API's. Some other observations:
- Apollo uses WebKit as it's HTML engine, the same one that is used within the MacOS browser Safari.
- IDE development with Apollo only works with FlexBuilder 2.0.1 right now. If you want to use Eclipse and the free Flex SDK, you are out of luck for now and will be restricted to doing command-line development (or installing an evaluation copy of FlexBuilder).
- It is somewhat humorous that Apollo's built-in HTML engine doesn't deal with flash in a web page.
- As already mentioned, you will need the Flex SDK in some form to have the Apollo SDK work.
- I was't able to get the packaging command, adt, to work for me. It returns a "null" error.
Overall, the Alpha1 SDK has a complete component GUI, since it leverages Flex, and basic integration with the OS and HTML engine. We'll have to await a future release to see all of the things that will make developing robust RIA's on the desktop (offline + security) pleasant and easy.
Topics: Apollo
Why User Research Matters
What if you brought in users to test your application and the final result was one big collective yawn. It’s not that the product wasn’t usable -- oh, maybe some minor tweaks to the presentation layer could improve things, but overall all tasks were completed fairly well. No, it’s more that the users had no desire to use your product because, well, because quite frankly it didn’t answer their needs. In short, the proposition was wrong from the very beginning.
To steal a quote from disambiguity: "If you’ve got a flaw in your thinking at the top of the chain, then no amount of surface usability is going to save your product."
I know it sounds fundamental, but the fact is that the value proposition you’re offering needs to solve real problems for real users. Concepts are great and brainstorming is fun, but if the user is not an integral part from the very beginning, they may decide they don’t want any part of the result.
The good news is that the value proposition can easily be validated by conducting user research early on in the project cycle. Talk to the people you’re designing for, understand their needs and check to see whether or not your ideas and concepts are on the same page with their goals.
Usability starts at the very beginning, with user research. For a minimal amount of time invested at the start of a project, you’ll save yourself a lot of wasted time wandering down the path of functionality that solves the wrong problems or even worse, is not even wanted by the users.
Topics: User Research
Ideas for User Research
User Research isn't limited to sitting behind a glass window, nervously chomping on M&Ms while glaring at the hapless user who’s attempting to navigate through your next killer app. There are different types of user research that can be incorporated throughout the lifecycle of a project, often at minimal costs to the company but with maximum results towards a more usable product.
User research methodologies generally fall into the two broad categories of Qualitative (why is something happening) and Quantitative (what is happening). With Qualitative research, you use a small sample size to discover new insights which can then be tested or proven. Quantitative research uses a large sample size to test or prove something, perhaps one of the insights you uncovered during your qualitative research or to determine the primary browsers you want to support.
Starting with Quantitative Research, here are some methods you should consider incorporating into your next project:
User Surveys uncover what the users say. You’ll get a large sample of responses on your users’ goals, behaviors and attitudes (assuming you have a well-designed survey of course). Surveys allow you to easily gather data on almost any topic and the results can then be ranked and assigned a priority for future design, scoping, etc..
Site Traffic Analysis tells you what your users do. An analytics tool's output tell you how your site is navigated, which pages are abandoned, which content performs well, which browsers you users are actually using, and so on. Your logs files will tell you some of this information as well, but slog through those files just once and you’ll soon realize the value of an analytics tool.
Information from these Quantitative research methods will tell you what is happening but not necessarily why it’s happening. For that, you’ll need to conduct some sort of Qualitative research, such as:
User Interviews let you learn about your users. Either from talking to a person face-to-face or over the phone, interviews yield detailed information about your users’ goals, behaviors and attitudes. They are usually better when conducted one on one rather than in a group because you can remain focused on that one individual and what they're saying. Keep in mind that loosely constructed conversations, rather than a formal script, allow for unexpected tangents that can lead to surprises and insights.
From Field Studies, you’ll gain context about where and how and when people actually use your software (or the competition) as you observe them in their daily routines. From this direct observation, you’ll also gain an understanding of your user’s attitudes and perceptions which will help in designing the user experience.
Usability Testing is done to observe user behavior. It is different from a field study in that you’re not merely observing the users' actions, but you’re also directing their actions. It lets you watch how people use your application to perform specific tasks and where they encounter obstacles, which features slowed them down, which elements were confusing, etc. Usability Testing yields a richer quality and quantity of information than a survey.
Topics: Usability Testing, User Research
Wt - Another Server-Side Ajax Framework, This Time in C++
We've had two server-side Ajax frameworks for a while now -- Echo2 and ZK -- that tranform web development into desktop GUI development. Now add a third: Wt, or "Witty" as it's known (here for tutorial), is a C++ framework. From the tutorial above, a classic manifesto of the server-side Ajax framework:
Because the API of Wt makes abstraction of the underlying technologies (Forms, JavaScript or AJAX), Wt chooses how to communicate with the web browser depending on technology support in the browser. The responsibility for making the application work in the jungle of web browsers is therefore also transferred from the application developers to the library developers.
The framework has most of the usual widgets and behaviors, including a tree widget and drag and drop.
Now my last serious C++ project was in institutional mutual fund trading system back in 1998, so I'm as rusty as Davey Jones' belt buckle when it comes to that language. To top it all off, I have Java and C# running through my brain, so I'm likely to introduce illigitimate syntax from these close cousins; but I know there are still plenty of talented and experienced programmers out there working with C++. More importantly, three frameworks officially makes for a trend, which means server-side component GUI frameworks are officially a "good idea."
Topics: Ajax Frameworks, Echo2, ZK
The Hazards of Blog Editing Software
Somewhere along the way in yesterday's post about JSONP, I made an edit and an empty DIV got swallowed. The result was a somewhat underwhelming demo where you pushed the button and nothing happened. I've fixed the post and, hopefully, it all works now.
Topics: Editorial
101 Ideas for JSONP - Idea #3: Scraping HTML With TagSoup and XQuery
Now that we have two ways (here and here) to pull XML data into our Ajax apps via JSONP, it's time to talk about how we can get our hands on more interesting data. Our two techniques allow us to proxy services that already produce valid XML, but not everything is available in this form. Lots of groovy data is still locked away in tradition web applications.
You can see an example of this problem even over at the leader in JSONP web services, Yahoo!. While Yahoo! provides an excellent delayed stock quote service, one thing that is lacking is a corresponding ticker lookup service. They do however have a ticker lookup web app: http://finance.yahoo.com/lookup?t=S&m=US&s=IBM
Transforming this app into a service involves the usual calisthenics -- transform the crappy HTML into well formed XHTML and then extract and transform our desired data into valid XML. Now we could use XSLT to crack this nut, but every time I break out the XSLT I get flashbacks to my Recursive Function Theory course and think that I'm doing a proof. Truth be told, I've never been a big fan of functional programming; FLWR expressions just seem so much easier to write. Yes, there are times where performance dictates not using XQuery, but for this example I'm sticking with my preference.
Below is a query that will perform our desired extraction and transformation. (XQuery syntax is a little beyond the scope of this post, but for a quick tutorial see here.) Like all screen scraping, it is a little brittle. If Yahoo! decides to change the format or even the color of the header row in this return page, the thing breaks. There are other queries that will do the trick and maybe be a little less brittle, but you should build some sort of regression testing and notification into these sorts of screen scrapers for precisesly these reasons. When it breaks, you know about it and you can fix it quickly.
<entities>{ for $t in //*:table[*:tr[@bgcolor="dcdcdc"]] for $r at $position in $t/*:tr[count(child::*:td)>1] where $position != 1 return <entity> <symbol>{data($r/*:td[1])}</symbol> <name>{data($r/*:td[2])}</name> <market>{data($r/*:td[3])}</market> <industry>{data($r/*:td[4])}</industry> </entity> } </entities>
To apply this to the Yahoo! ticker symbol lookup, we use a combination of the Nux XML processing toolkit and the TagSoup parser. TagSoup is the weapon of choice for converting gnarly HTML to well formed XHTML, and Nux gives us the XQuery machinery we need. Here is the code snippet for scraping the ticker symbol information from the results page:
private String applyScript(String uri) { InputStream in = null; GetMethod get = new GetMethod(uri); get.setFollowRedirects(true); try { httpClient.executeMethod(get); in = get.getResponseBodyAsStream(); } catch (IOException e) { log.error("Problem getting uri feed " + uri, e); return JSONIdeasConstants.ERROR_XML; } try { XMLReader parser = new org.ccil.cowan.tagsoup.Parser(); // tagsoup parser Document doc = new Builder(parser).build(in); Nodes results = XQueryUtil.xquery(doc, xqueryScript); if (results.size() < 1) { return JSONIdeasConstants.ERROR_XML; } return results.get(0).toXML(); } catch (ValidityException e) { log.error("Problem getting uri feed " + uri, e); return JSONIdeasConstants.ERROR_XML; } catch (IOException e) { log.error("Problem getting uri feed " + uri, e); return JSONIdeasConstants.ERROR_XML; } catch (ParsingException e) { log.error("Problem getting uri feed " + uri, e); return JSONIdeasConstants.ERROR_XML; } }
Here xqueryScript is a String containing the above XQuery script text. The ERROR_XML is just a constant string, "<Error></Error>", that we send back to the caller in case of an error. (You may want to send back a more informative error message to the browser. We'll tackle that in a later post.) This code will end up transforming the following app output...
...into the following xml
<entities> <entity> <symbol>IBM</symbol> <name>INTL BUSINESS MACH</name> <market>NYSE</market> <industry>Diversified Computer Systems</industry> </entity> <entity> <symbol>HZK</symbol> <name>CORTS TR VI IBM DEB</name> <market>NYSE</market> <industry>N/A</industry> </entity> <entity> <symbol>HZD</symbol> <name>6.40% CORPORATE-BACK</name> <market>NYSE</market> <industry>N/A</industry> </entity> <entity> <symbol>KVM</symbol> <name>STR PD 7.0 CORTS IBM</name> <market>NYSE</market> <industry>N/A</industry> </entity> <entity> <symbol>GJI</symbol> <name>SYNTHETIC FXD INC</name> <market>NYSE</market> <industry>N/A</industry> </entity> </entities>
Submitting the query is just the same old thing we've done before, just grab the input field contents and pass it to our servlet via an insert script operation:
JSONPIdeas.lookupSymbol = function() { var query = $("#lookup").val(); JSONPIdeas.addScript("http://labs.pathf.com/JSONIdeas/TickerLookup?callback=JSONPIdeas.renderSymbols&query=" + query); }
Give the example below a try. You can see the Javascript source code involved in this here. Note that if there is only one entity, the JSON lib that converts the XML into JSON doesn't return an array, so we check for that.
---
I hope I've inspired you to write some of your own JSONP web services. Next time I'll tackle some of the security issues that JSON and JSONP raise.
Installing Software? Nah, I have a Browser
Let me tell you about my day which, for most of you, will sound very familiar (the actions if not the details).
When I came home, I was glad to see that not only had my Netflix DVD arrived, my updating of my queue was successfully completed before this latest mailing was sent out. Putting the movie aside momentarily, I popped online to pay a bill because I realized I had never received the paper bill which should have arrived by now. But no worries here because I figured there was an online option available, which there was, so I easily took care of that outstanding item.
I then jumped over to the Benjamin Moore site and, using their interactive tools, was able to see what my friend’s house rehab will look like with the colors she’s selected. It should end up looking very nice. Then, being the good daughter that I am, I sent my mom some flowers (to celebrate the warmer weather that will surely arrive one of these days!) before settling in and watching my movie.
So in one evening I received the correct product thanks to real-time data management, accessed an accounts payable system, an interactive color tool, and a purchasing system. The Web has become an integral part of our lives, evolving from a static, digital publishing medium into a series of interactive applications that we use on a daily basis.
What struck me about all of this, however, is that not once did I have to insert a disk and install software in order to take advantage of what’s out there. Now perhaps you don't consider what you’re viewing on the web as software, but consider this: moving forward, we’re seeing an increase in the availability of hosted apps such as Google’s docs and spreadsheets and Adobe’s soon to be released online version of Photoshop. Features that used to require loading software in order to access are available via a web browser. Makes you wonder if maybe that dvd tray *is* a cupholder after all!
Is Javascript the Assembly Language of Web 2.0?
I went home for my father's 77th birthday last weekend. Besides catching a bad stomach flu that has laid me out for the last few days, I also had a little browse down the memory bookshelf. In with Plato's Republic I found a few of my less useful CS books -- 80x86 and 68k assembly language books, Fortran, PASCAL -- that I haven't bothered to include in my working programmers library. I rarely have to look at any legacy Fortran or PASCAL, and I haven't had to do any assembly language in forever. I've toyed around with assembly language for the JVM, but more as a curiosity. Unless you are a kernel or compiler writer, there just isn't much call to do it.
Now I've interviewed and worked with lots of developers over my career. Just taking the last seven, say since 2000, I've noticed a real drop off in those who have studied assembly language programming. Now why would I care about whether programmers are knowledgeable in a skill that I myself don't even use? Why should I value such an impractical skill? Well, because I think that solving problems using assembly language gives you a deeper insight into the workings of the underlying hardware and, more importantly, imposes a certain mental discipline on the problem solver. The same thing is true for programming with punch cards. I may be one of the youngest people around who actually wrote code on punch cards and fed it to an ever obliging Amdahl (an IBM mainframe clone at SUNY Binghamton, near the birthplace of IBM, eegads).
Having to retype your code a card at a time (no backspacing, baby, and no code completion) and waiting for up to an hour to find out you had committed a logic or syntax error, makes you ruthless and efficient in your debugging and problem solving. For guys like me, symbolic debuggers and all the crutches that an IDE provides seem like junk food for the programmer's mind. Of course, once you've used tools like Resharper, a plugin that makes Visual Studio a pleasure to use, you have to allow yourself a few development Fruit Loops.
I see the same sort of evolution with the browser platform. The appearance of well engineered frameworks that simplify, hide or eliminate the need to know Javascript, CSS or XHTML, is the beginning of the end of Javascript as a core skill set for web development. It may not seem obvious now, of course; after all, there seems to be more Javascript development going on than ever before, but the trend toward Javascript-free Ajax and web development is rooted in this furious framework activity.
And that trend disturbs me for the same reasons that the trend away from Assembly language disturbed me: a lack of mental rigor and an ignorance of the underlying platform. Maybe I'm a fuddy-duddy as described in On the necessity of removing "cruelty" from the teaching of computing by Tony Clear:
They bewailed the dumbing down of programming, with COBOL's grandiose claims to remove the need for good old assembly language programming. It was going to make programming easy, as later would fourth generation languages and all the subsequent over-hyped marketing exercises proposing the end of programming.
The impetus for this article was the talk by Edsger Dijkstra entitled On The Cruelty of Really Teaching Computing Science. He was arguing for the teaching of CS as a mathematical discipline. The debate has moved on, but one of my favorite statements on the mixed blessing of applying computers to real world problems:
The business community, which, having been sold the idea that computers would make life easier, is mentally unprepared to accept that they only solve the easier problems at the price of creating much harder ones.
It's good advice to keep in mind as we solve the "easy" problem of making web applications more powerful and easier to develop.
Topics: Editorial
From spam to slam
Chicago graduate student Kristin Thomas has found a creative way to recycle her spam e-mail by constructing poems using only the subject lines of the unwanted correspondence. “I don’t like to get angry, and I was starting to get angry,” Thomas says. “One day I was looking at all of this stuff in my inbox—something like 2,000 pieces of e-mail, none of it from anyone I knew. When I was scanning the subject lines, something caught my eye, and it just sounded like slam poetry. And I wasn’t angry any more. It was a peaceful way to resolve the issue—because spam isn’t going away.”
While I’m still waiting for my share of fifty (50) million dollars from my investment partner in Nigeria, Thomas “repurposes” her email headers and posts them on her website. In an interview in the Chicago Sun-Times, she shared one of her favorites:
“it counts”
3 Chicks in one night
(25 mg did the trick.)
3 hand made silk ties
3 dollars, each
4 out of 5 doctors recommend
5 financial tips for grads
6 times the action
7 minutes in heaven!
15 minutes of waiting and then
36 hours of pleasure!
Numbers never lie my friend
Numbers never lie
About Pathfinder
Recent
- Making GWT JSON not Quite so Painful
- IDEA - preconference workshop 06 Oct 08
- HTML5, Ajax history management, and The Ajax Experience 2008 Boston
- A Look Back At Past Posts
- Flash Player on iPhone gossip
- Microsoft to Jump on Board EC2
- TAE Boston 2008: The Unsexy Presentations
- The Ajax Experience 2008: Hope to see you in Beantown
- TankEngine: New plugin for Rails iPhone Development
- Symphony of Ruby on Rails and Flex through RubyAMF
Archives
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Topics
.NET
2d physics
3d
3D GPS
3D physics
37signals
Accessibility
actionscript
activerecord
Add new tag
Adium
ADO.NET Entity Framework
Adobe
Adobe AIR
Advertising
agile
Agile Development
AIR
Ajax
Ajax Applications
Ajax Bookmarking
Ajax Components
Ajax Development
Ajax Examples
Ajax Experience
Ajax Frameworks
Ajax history management
Ajax Intervention
Ajax libraries
AJAX Obfuscation
Ajax Performance
Ajax Products
Ajax Tools
Ajax Widgets
Amazon
amf
Analysis
Android
Announcement
Announcements
antennae
Apollo
Application Architecture
Application Development
AS3
ASP.NET
Asynchronous Processing
awards
Back Button
Benchmarking
Best Practices
BitmapData.draw
BJAX
Blaze Advisor
blog
blogging
Books
Browsers
Business
Business Reasons for Ajax
Business Rules
C#
Canvas
Case Studies
chess
Chicago
Cloud Computing
CMS
COBOL
code art
Code Generation
Color
COMET
Conference
Consistency
Content Management
CRM
CruiseControl
CSS
Custom Flex Component
data visualization
Degrafa
Design
Design Patterns
Desktop
Desktop RIA
Developer's Notebook
Diagnose
Dojo
Domain Knowledge
Drools
EC2
Echo2
Echo3
Editorial
ERP
Ethnographic Research
events
externalinterface
Ext JS
Facebook
ferret
FileReference
Firefox
Firefox Extensions
Flash
flash awards
flash player
flash player 10
Flex
flexunit
Flock
Flow
Frameworks
front end
front end development
Games
Gauge Component
getting things done
Git
Google
Google calendar
Google Gears
Grails
Graphics
Greasemonkey
Groovy
GStreamer
GTD
Gwittir
GWT
Healthcare
Hibernate
Hudson
IDE
Ideation
IE
IE6
IE7
IE8
ILOG JRules
Information Architecture
Innovation
Instructional Design
Interaction Design
Interview
iPhone
iTunes
Java
Javascript
JavaScript frameworks
Javascript Libraries
JBoss Rules
Jess
Jetty
JIT
Jobs
jQuery
JSF
JSON
JSR-94
JsUnit
Lazlo
Legacy Systems
lightweight
LinkedIn
LINQ
Logical Model and Conceptual Model
Low Pro
Mac
Mash Note
Mashups
Meebo
MetaWidget
Methodology
Microformats
Microsoft
Mobile
Mootools
mouse scroll
mouse wheel
Mozilla
Music
MVC
MySql
NetNewsWire
Object-Oriented
Object Relation Mapping (ORM)
Office
OOP
Open Screen
Open Source
Opera
Oracle
ORM
osx
pagination
Pair Programming
papervision3d
Patterns
Peer Creation
Performance
Personas
PHP
physics
physics engines
plugin
preloader
process
Web/Tech
Product Definition
productivity
Progressive Enhancement
Project Website
Prototype
Prototyping
PV3D
QA
qooxdoo
Radiant CMS
rails
Really Simple History
References
Requirements
Requirements
Alice Toth
Requirements Visualization
Restlet
RETE
Review
Rich Interactions
ruby
rubyamf
Ruby on Rails
SaaS
Safari
San Francisco
Scalability
Scenarios
Scriptaculous
SDLC
Search
Security
Selenium
Semantic web
SEO
Server Side
Silverlight
SOA
Social Networking
Software Processes
Songbird
SpiderMonkey
Sprajax
Spreadsheets
Standards
Startups
STI
Story Telling
Struts
Tamarin
Task Flows
Test Driven Development
Testing
The Ajax Experience
Tilt Component
Tools
TraceMonkey
Training
Trends
Tumblr
Tutorial
Tutorials
Unit Tests
Usability
Usability Testing
User Experience
user experience design
user interface
User Interface Standards
User Research
UXD
Venture Capital
Video
Vision
Visualization
VLC
Volta