The world has changed. People previously used a piece of software, couldn't figure it out, and said "I'm just not good with computers." Now people use a piece of software, can't figure it out, and say "This is poorly designed."
The second answer, as it turns out, was the right answer all along. But decades of cultural training led to the general public to believe that 'computers' were hard. People still believe that, actually.
What's funny is that they don't call their tablet or smartphone a 'computer', but it is. They're just computers with a more human-natural interface.
The mass use of these natural interface computers (tablets and smartphones) has exposed the general public to usable software. The public knows that working software can be instinctive and intuitive. They no longer automatically assume that they are at fault when it's hard. They now correctly assume that it's the designer's fault.
This changes everything. People expect all software to be easy to use, from the ATM to their favorite website to their video game interfaces. Easy-to-use is no longer a luxury, it is a requirement.
Monday, October 1, 2012
Friday, September 21, 2012
Tool Based Development vs Tool Based Developers
Tools are meant to increase the efficiency of putting knowledge into practice, not to replace knowledge itself.
Tool Based Developers
There is a large difference between tool based development, and tool based developers. The tool based developer sits in a dangerous abstraction point. He is aware of the tool, and the results of the tool, and yet lacks knowledge of what the tool is actually doing to accomplish its task.
There are many weaknesses to the tool based developer. If you make an honest self-examination, and discover that you fall into this category, you must be aware that your reliance on others' work stifles your growth, and ultimately will be to your detriment.
Below are some of the weaknesses of the tool based developer:
Tool based development
Definition:
A "good enough" technique is a technique in which the developer, because of the inability to solve a problem, implements a solution that is "good enough." The solution closely resembles what was required, but is not exact in its response. The solution will pass initial scrutiny, but will be unable to support deeper requirements.
Tool based development
Sidenote:
Tools are often designed to generate code that they themselves can easily translate back into the interface. Therefore the code generated may not be the best way of implementing a solution (though it may "work"). Observing what the tool does can give you clues and ideas - not an education. Tool based development is good. Being a tool based developer is dangerous. There is a simple rule to remember (for Windows users anyway): if you can't do it in Notepad you don't actually know how.
In other words:
Be able to do it without the tool first, then, once you have understanding, use the tool to increase your efficiency.
A chef prepares a meal. He cooks nearly everything from scratch. There is one particular part of the meal (the sauce) that he could prepare in its entirety, but instead he chooses a popular "out of the can" sauce that tastes just as good as his "from scratch" recipe. He has the knowledge, but uses the tool to increase his efficiency without losing quality. He is a chef who implements tool based cooking.
The tool based chef, however, can't cook anything that doesn't come in a can. He may make a fair meal, but it isn't the best possible, and there is a direct relationship between the weakness of the tool (the stuff in the can) and the weakness of his meal. If one is bad, the other will be as well. He has limited himself, and those eating his food because, although fed, they may suffer adverse consequences (i.e. a bad tasting meal or upset stomachs).
This, in essence, is the difference between tool based development, and tool based developers.
The tool based chef, however, can't cook anything that doesn't come in a can. He may make a fair meal, but it isn't the best possible, and there is a direct relationship between the weakness of the tool (the stuff in the can) and the weakness of his meal. If one is bad, the other will be as well. He has limited himself, and those eating his food because, although fed, they may suffer adverse consequences (i.e. a bad tasting meal or upset stomachs).
This, in essence, is the difference between tool based development, and tool based developers.
Tool Based Development
A good developer is an efficient developer. For this reason, it is folly to simply reject IDEs and WYSIWYG editors for the command line and hand coding everything. If there is a tool available that can help get a developer's job done more quickly without sacrificing quality, then the developer uses it.
Thus we arrive at the concept of tool based development. A core part of our development methodology is the proper utilization of tools. A developer should be aware of the best tools available to do a job. A developer should understand the quality of the resulting output of such tools. A developer should be willing to use a tool if it saves time and money.
Those who employ development tools (such as Visual Studio among others) have a thorough knowledge of the tool. They are aware of all of its facets that apply to their development needs. A development team should standardize on a set of tools, and be willing to upgrade or change if better tools become available.
The developer is also aware of the weaknesses of the tool. The developer does not immediately implement a process through some device the tools offers, without first lowering his abstraction point to examine the entire scope of the entire project or process, and its ultimate goals. If the tool's methodology saves time in the immediate, but greatly complicates later stages of development, extensibility, or maintainability, then that tool's methodology is rejected.
The developer who implements tool based development is not afraid of problems which the tool cannot solve. He or she has an understanding of the process the tool is optimizing, and dig into that process to get the most out of his development environment.
Tool based development involves using the tool where it increases efficiency without losing quality, and ignoring the tool where it does not.
A good developer is an efficient developer. For this reason, it is folly to simply reject IDEs and WYSIWYG editors for the command line and hand coding everything. If there is a tool available that can help get a developer's job done more quickly without sacrificing quality, then the developer uses it.
Thus we arrive at the concept of tool based development. A core part of our development methodology is the proper utilization of tools. A developer should be aware of the best tools available to do a job. A developer should understand the quality of the resulting output of such tools. A developer should be willing to use a tool if it saves time and money.
Those who employ development tools (such as Visual Studio among others) have a thorough knowledge of the tool. They are aware of all of its facets that apply to their development needs. A development team should standardize on a set of tools, and be willing to upgrade or change if better tools become available.
The developer is also aware of the weaknesses of the tool. The developer does not immediately implement a process through some device the tools offers, without first lowering his abstraction point to examine the entire scope of the entire project or process, and its ultimate goals. If the tool's methodology saves time in the immediate, but greatly complicates later stages of development, extensibility, or maintainability, then that tool's methodology is rejected.
The developer who implements tool based development is not afraid of problems which the tool cannot solve. He or she has an understanding of the process the tool is optimizing, and dig into that process to get the most out of his development environment.
Tool based development involves using the tool where it increases efficiency without losing quality, and ignoring the tool where it does not.
Tool Based Developers
There is a large difference between tool based development, and tool based developers. The tool based developer sits in a dangerous abstraction point. He is aware of the tool, and the results of the tool, and yet lacks knowledge of what the tool is actually doing to accomplish its task.
There are many weaknesses to the tool based developer. If you make an honest self-examination, and discover that you fall into this category, you must be aware that your reliance on others' work stifles your growth, and ultimately will be to your detriment.
Below are some of the weaknesses of the tool based developer:
Fragile abstraction point
The abstraction point of the developer is extraordinarily fragile. If any requests are made that fall outside of the scope of the tool (or the scope of the developer's understanding of the tool), the developer will be unable to implement an elegant solution.
In fact, the developer may be unable to implement a satisfactory solution of any kind - resorting instead to a tool based solution that resembles at the surface to be what was requested. However, upon deeper examination, the solution will show itself to be at worst inadequate, and at the least extremely difficult to extend or maintain.
Lack of problem solving ability
In fact, the developer may be unable to implement a satisfactory solution of any kind - resorting instead to a tool based solution that resembles at the surface to be what was requested. However, upon deeper examination, the solution will show itself to be at worst inadequate, and at the least extremely difficult to extend or maintain.
Lack of problem solving ability
The tool based developer is weak in the area of problem solving ability. He or she has become so reliant on the tool to do their work for them, that problems which fall outside of that scope of knowledge (i.e. below their abstraction point) are met with confusion, disappointment, desperation, and sometimes anger.
This developer spends an inordinate amount of time searching for other person's solutions to various problems. Failing to realize that every scenerio may be different, the developer reacts to every problem below his or her abstraction point by looking for "the code to" solve it.
Fragile results
Many times what the tool based developer develops at first seems to satisfy all requirements. It "works". However, the process is extremely thinly abstracted making it very difficult to satisfy user requirements once change requests are made. Extending the application to service other needs is difficult, perhaps even impossible.
Ultimately both the user and the developer will regret his or her methodology. Their applications are burdensome (to both the user and the developer), inefficient, and ultimately more financially expensive because the difficulty of extensibility and maintenance.
Deceptive qualifications
This developer spends an inordinate amount of time searching for other person's solutions to various problems. Failing to realize that every scenerio may be different, the developer reacts to every problem below his or her abstraction point by looking for "the code to" solve it.
Fragile results
Many times what the tool based developer develops at first seems to satisfy all requirements. It "works". However, the process is extremely thinly abstracted making it very difficult to satisfy user requirements once change requests are made. Extending the application to service other needs is difficult, perhaps even impossible.
Ultimately both the user and the developer will regret his or her methodology. Their applications are burdensome (to both the user and the developer), inefficient, and ultimately more financially expensive because the difficulty of extensibility and maintenance.
Deceptive qualifications
The tool based developer may have read every book on his or her field, and can often sound knowledgeable in an interview. He or she may be able to throw about technical terms and buzz words - however this banter is surface only. While able to quote from a book about what a particular concept is, they lack actual understanding.
As a result of this, the tool based developer's qualifications are deceptive. The developer finds his or herself in a job being given an assignment, and the developer's qualifications pass initial inspection. However, as time passes, their inability to problem solve, the inefficiency and lack of scalability of their applications, and the time it requires to implement a solution become manifest.
The tool based developer may find him or herself without work on repeated occasions, which is unnecessary since they are quite likely a bright person who simply does not understand their abstraction point nor how to change it.
Every developer must be wary of being or becoming a tool based developer. Do not simply accept new tools without understanding what they are doing for you. Lower your abstraction point. Only then will you build quality applications, and be able to grow to your fullest potential.
Examples
Here is a classic example. HTML (HyperText Markup Language) is the core language of the internet. It (along with the CSS specification) defines how an internet browser displays a web page.
Here are two examples (based on the web development world and HTML) of the difference between tool based developers and tool based development:
Example #1: Page layout
As a result of this, the tool based developer's qualifications are deceptive. The developer finds his or herself in a job being given an assignment, and the developer's qualifications pass initial inspection. However, as time passes, their inability to problem solve, the inefficiency and lack of scalability of their applications, and the time it requires to implement a solution become manifest.
The tool based developer may find him or herself without work on repeated occasions, which is unnecessary since they are quite likely a bright person who simply does not understand their abstraction point nor how to change it.
Every developer must be wary of being or becoming a tool based developer. Do not simply accept new tools without understanding what they are doing for you. Lower your abstraction point. Only then will you build quality applications, and be able to grow to your fullest potential.
Examples
Here is a classic example. HTML (HyperText Markup Language) is the core language of the internet. It (along with the CSS specification) defines how an internet browser displays a web page.
Here are two examples (based on the web development world and HTML) of the difference between tool based developers and tool based development:
Example #1: Page layout
Tool based development
The developer chooses a WYSIWYG tool (like Dreamweaver or Frontpage) to layout his page. The tool greatly increases the efficiency of doing this work.
Let us suppose developer hits a particular aspect of the layout that is difficult to implement. He switches from WYSIWYG mode to HTML mode (i.e. look at the code rather than the tool's interface), thereby lowering his abstraction point, adjusts the HTML to fit his needs, and climbs back up the abstraction ladder returning to the tool's interface.
Tool based developer
Let us suppose developer hits a particular aspect of the layout that is difficult to implement. He switches from WYSIWYG mode to HTML mode (i.e. look at the code rather than the tool's interface), thereby lowering his abstraction point, adjusts the HTML to fit his needs, and climbs back up the abstraction ladder returning to the tool's interface.
Tool based developer
The tool based developer does not know (or does not have an adequate knowledge of) HTML. Although calling him or herself a "web developer", he or she lacks knowledge of the very core of their field! They use the tool, and when reaching an aspect of the layout that is difficult to implement, he or she relies on tricks, workarounds, or "good enough" techniques to be able to simply move past a hurdle that could have helped them grow as a professional.
A "good enough" technique is a technique in which the developer, because of the inability to solve a problem, implements a solution that is "good enough." The solution closely resembles what was required, but is not exact in its response. The solution will pass initial scrutiny, but will be unable to support deeper requirements.
Example #2: Code generated HTML
Tool based development
There are various platforms on which to implement web applications (like PHP, Ruby on Rails, or ASP.NET), however all have the same simple goal: to deliver HTML to the user. They may allow for object-oriented programming, file and database manipulation, and business rule enforcement - but the ultimate goal does not change. Tool based development involves using the platform to output the desired HTML.
The developers knows ultimately the HTML he or she desires, and manuevers the coding platform to output just such HTML. This means he or she understands how the coding platfrom generates its HTML, so as to be able to adjust accordingly.
Tool based developer
The developers knows ultimately the HTML he or she desires, and manuevers the coding platform to output just such HTML. This means he or she understands how the coding platfrom generates its HTML, so as to be able to adjust accordingly.
Tool based developer
The tool based developer does not appreciate that the coding platform is merely rendering a service, and is not the ultimate medium through which the user is interacting with the application. Because of this the user interface may be sloppy and disorganized.
The developer fails to understand that when he or she (for example, in Visual Studio, or Dreamweaver) "drags and drops" a multiline textbox onto his WYSIWYG editor, that visually displayed item is a translation of a simple "<textarea>" tag that the browser will interpret. The tool is doing the same work as the browser: interpreting an abstract concept, thereby raising the abstraction point of the user.
Because of lacking knowledge of HTML itself (and we may go to lower abstraction points, as in the way individual browsers interpret HTML, or as in how the Internet actually works) more intricate and elegant interface designs are beyond his or her ability.
The developer fails to understand that when he or she (for example, in Visual Studio, or Dreamweaver) "drags and drops" a multiline textbox onto his WYSIWYG editor, that visually displayed item is a translation of a simple "<textarea>" tag that the browser will interpret. The tool is doing the same work as the browser: interpreting an abstract concept, thereby raising the abstraction point of the user.
Because of lacking knowledge of HTML itself (and we may go to lower abstraction points, as in the way individual browsers interpret HTML, or as in how the Internet actually works) more intricate and elegant interface designs are beyond his or her ability.
Sidenote:
There is also the danger of attempting to learn the needed core knowledge solely by observing what the tool is doing (in our HTML example, drag and drop followed by looking at the HTML generated). This is a fine way of gaining some knowledge - but you are potentially limiting or even damaging yourself.
Tools are often designed to generate code that they themselves can easily translate back into the interface. Therefore the code generated may not be the best way of implementing a solution (though it may "work"). Observing what the tool does can give you clues and ideas - not an education. Tool based development is good. Being a tool based developer is dangerous. There is a simple rule to remember (for Windows users anyway): if you can't do it in Notepad you don't actually know how.
In other words:
Be able to do it without the tool first, then, once you have understanding, use the tool to increase your efficiency.
Thursday, September 20, 2012
Write LESS in Web Matrix
I love LESS. Anything that allows me to code faster and cleaner is a good thing. Microsoft's free Web Matrix 2 now supports LESS CSS. Way cool.
http://www.microsoft.com/web/post/how-to-use-less-css-in-webmatrix
If you haven't tried LESS, give it a try. (Side note: Some like SASS better. I personally like LESS because of the javascript compiler, however SASS is more powerful.)
http://www.microsoft.com/web/post/how-to-use-less-css-in-webmatrix
If you haven't tried LESS, give it a try. (Side note: Some like SASS better. I personally like LESS because of the javascript compiler, however SASS is more powerful.)
Spurious Bing challenge
Microsoft has been touting its BingItOn challenge on television and the web, purporting to be a fair, blind comparison test between google and bing web searches.
I think this is a spurious claim. Microsoft is including UX from Bing, that is not being included in its Google search results.
Here's what I see at BingItOn if I search for Cleveland, OH:
The right looks like the obvious winner, no? Why? Because it includes useful UX elements, like plane flights, weather, etc. Turns out that's the Bing side. The left side is the Google side which looks pretty sad. So I pick the right side. Here's the problem - check out what the same search looks like on Google:
The Google search results does indeed include the same UX elements as Bing, actually it includes more. To be fair, the Google API (which I imagine Microsoft is using) may not bring these elements back, however it is clear that the comparison test is not a fair one.
Microsoft is claiming that Bing beat Google 2 to 1. However if the full user experience of both sites is not presented, how is that a fair comparison?
I think this is a spurious claim. Microsoft is including UX from Bing, that is not being included in its Google search results.
Here's what I see at BingItOn if I search for Cleveland, OH:
 |
| BingItOn search for Cleveland, OH |
The right looks like the obvious winner, no? Why? Because it includes useful UX elements, like plane flights, weather, etc. Turns out that's the Bing side. The left side is the Google side which looks pretty sad. So I pick the right side. Here's the problem - check out what the same search looks like on Google:
 |
| Google search for Cleveland, OH |
The Google search results does indeed include the same UX elements as Bing, actually it includes more. To be fair, the Google API (which I imagine Microsoft is using) may not bring these elements back, however it is clear that the comparison test is not a fair one.
Microsoft is claiming that Bing beat Google 2 to 1. However if the full user experience of both sites is not presented, how is that a fair comparison?
Wednesday, September 19, 2012
Microsoft.com does good, then hides it
Here's a rule about homepage design: Focus your homepage on the primary reasons why someone comes to your website.
The navigation bar at the top of Microsoft.com does a fantastic job of this.
- It offers their primary products as the largest, most obvious links.
- It separates those coming for 'home' products versus 'work'.
- It offers the most popular destinations, which are the most likely reasons for someone to be there.
 |
| Good UX behind bad UX |
Too bad they hide all of this behind a tiny arrow icon at the top left corner of the page - and you have to click the arrow itself, not the whole Microsoft logo. Good UX inside of here - why hide it? This should be the homepage.
Tuesday, September 18, 2012
Developers Shouldn't be Highly Abstracted
Telerik put out their platform guidance for Microsoft.NET: http://www.telerik.com/platformguidance.aspx
I disagree with one recommendation: Web Forms for interactive web applications (form over data). Their logic is essentially that asp.net web forms "Abstracts the need for developers to master JavaScript, HTML (compared to MVC)."
Years of asp.net web forms' existence proves the contrary. Developers who build web applications without understanding the very medium in which they work are likely to fail. The moment they hit a problem which requires going a level of abstraction deeper than the HTML being generated for them, they hit a massive wall.
Kudos to Telerik for an interesting breakdown. Boo for pushing developers towards a lack of understanding and a high abstraction point. If you want to build on the web, then you should know and understand HTTP, HTML, and these days, Javascript.
For interactive web applications in a Microsoft platform, HTML5, ASP.NET MVC, Web API, jQuery, and KnockoutJS for the win.
I disagree with one recommendation: Web Forms for interactive web applications (form over data). Their logic is essentially that asp.net web forms "Abstracts the need for developers to master JavaScript, HTML (compared to MVC)."
Years of asp.net web forms' existence proves the contrary. Developers who build web applications without understanding the very medium in which they work are likely to fail. The moment they hit a problem which requires going a level of abstraction deeper than the HTML being generated for them, they hit a massive wall.
Kudos to Telerik for an interesting breakdown. Boo for pushing developers towards a lack of understanding and a high abstraction point. If you want to build on the web, then you should know and understand HTTP, HTML, and these days, Javascript.
For interactive web applications in a Microsoft platform, HTML5, ASP.NET MVC, Web API, jQuery, and KnockoutJS for the win.
Monday, September 17, 2012
Banks are simplifying
Chase is updating their website to something simpler, soon to be released. Keybank did that not long ago. Portals are out, targeted pages are in.
What are the most common reasons someone comes to your website? Make that the easiest thing to do. The Keybank website is a good example of redesign with your users in mind. Chase may be learning that lesson as well.
What are the most common reasons someone comes to your website? Make that the easiest thing to do. The Keybank website is a good example of redesign with your users in mind. Chase may be learning that lesson as well.
What is the Abstraction Point?
Abstraction Point
/abˈstrakSHən/ /point/
noun phrase: 1. The degree to which a user is abstracted from the work done to implement their requested action.
/abˈstrakSHən/ /point/
noun phrase: 1. The degree to which a user is abstracted from the work done to implement their requested action.
Thursday, September 13, 2012
Living in Abstractions
We live in a world of abstractions. Everyday we take for granted the thought and care that has gone into our best experiences. We turn on the car, the faucet, or the computer, and don't give a second thought to its function unless it fails to do so.
For the designer of user experiences, it is imperative to understand the abstractions we live in, to embrace them, and to understand that every interface we design abstracts the user away from the technology underneath it.
In that regard, we reduce the need for unnecessary knowledge, and focus the user on the knowledge they have. We are not there to reduce their abstraction point. Thus we stand in the fog between use and understanding, at the point of abstraction in which the beautiful becomes useful, and the elegant goes unnoticed because it simply makes sense.
The point of abstraction for your user is the point where what they're doing makes sense to them, and to the system they are working in. Embrace your role as a builder of abstractions, for you must understand both the system and the psyche within them.
For the designer of user experiences, it is imperative to understand the abstractions we live in, to embrace them, and to understand that every interface we design abstracts the user away from the technology underneath it.
In that regard, we reduce the need for unnecessary knowledge, and focus the user on the knowledge they have. We are not there to reduce their abstraction point. Thus we stand in the fog between use and understanding, at the point of abstraction in which the beautiful becomes useful, and the elegant goes unnoticed because it simply makes sense.
The point of abstraction for your user is the point where what they're doing makes sense to them, and to the system they are working in. Embrace your role as a builder of abstractions, for you must understand both the system and the psyche within them.
Subscribe to:
Posts (Atom)