UI


Is Flash really going to die?


A couple a weeks ago I attended to the Web 2.0 expo, I did it for a few reasons, one was to learn from people, its incredible what you can learn just by talking with people in this kind of events, but also a very important reason was to know what is going on with the UI technologies today, what new companies are using, is people really implementing HTML5 features, what is the feeling about Flash/Flex etc. I was not surprise to me that many people are still relying in Flash in one or another way, some people choose Flex for different reasons, Video, more interactive UI, faster development, easy deployment, real time data, etc.

Many people tend to compare them and say that HTML5 will replace Flash, many of those are people that have never done any Flex/Flash application and probably don’t have the enough knowledge about Flash technologies to make that bold statement.

Before I say anything, I have to say that I like HTML very much, but I like Flash/Flex too. One thing is clear, “free and standard” technology is most of the time better than “proprietary standard” technology, but as always, your requirements should drive the decision of picking the right technology. Sometimes when you are trying to do something that “free and standard” can’t do, you can always consider a well accepted and distributed technology that gives you much more.

HTML5
-Is much more than just a structure markup language (currently there is a debate about HTML5 is the specification name only and still want to keep the name of HTML only), most of the time implicitly includes CSS, Javascrip, jQuery, Ajax, etc.
-Its currently W3C is currently in a draft format and constantly changing (Adobe, Google, Microsoft, Apple are participating).
- The big changes are:
- , , .
-Enriched semantics.
-Offline storage, database.
- More: http://www.xibl.com/web-development/html5-features-tips-and-techniques-you-%20must-know/

Ajax
At this point Ajax is a very stable and well accepted technology implemented successfully on many libraries. Mostly used on a HTML presentation but also used on Adobe Air.

Flash
Is a complete platform, not only a technology to build applications and not directly comparable to HTML.
It uses ActionScript that is ECMA262 based dialect for declaring dynamic behavior.
Includes side channel communications like RTMP.

They both things that the other one don’t have, and they both have cons.

For example:
Flash       HTML
Anyone can provide input?                      Yes         Yes
Standard can change? (Drop API)          Yes         Yes(Web SQL)
Vendor advantage or control                   Yes          Not likely- Possible
Consistent implementations                   (+) Likely (-) Likely
Speed of Innovation                                  Faster       Slower
Current state of innovation                     Active        Active

The truth is that HTML5 and Flash should not be compared at this point, HTML5 specification does not cover all the features that Flash provides, so Flash is still going to be the preferred technology for some kind of applications, and HTML5 new features will take a few years to be adopted by all the browsers (http://html5readiness.com/). There are enough applications out there and enough different requirements that both can live together and help each other.

I like to finish with a say from John Nack:
“This isn’t about one technology (HTML, Flash) vs. another; it’s about putting customers, and the solutions to their problems, ahead of any technology.”

Are you delivering an application from the 90′s?


At this point, we all should know about the importance of a UI Design and Usability in a Web 2.0 application, technology alone will never get the user acceptance and subsequent marketability without it. We have to agree that UI Design/Usability is that’s the face of the product and that’s how the user will evaluate the software, they will never know and don’t care what happen when they grabs the mouse and click that button.

We all have seen a lot of well architected projects fail because the the UI is ugly, cumbersome, is not easy to use, or gets the typical feedback from the user  “the previous app was better”, the typical reason? A bad User Interface Design. Most of the time this happens for two reasons, one is because the development team does not have a experienced modern UI/UX guy. A lot of projects do not take the UI seriously and that think that “UI Design is just picking a nice color and anybody can do that”, and do not hire somebody to do that job, letting the developers, business analysts, QA or experience users to guide the UI. The other reason is hiring the wrong UI designer. Some years ago when applications were just flat, design on HTML, PowerPoint or even just on a peace of paper was OK, but not any more, applications are a lot more interactive and applications designers need to get more technical.

To be a UI Designer you definitely need a big talent, but to be an UI Application Designer you need more than that, you need to be technical. Thanks to how technology has changed during the last few years, to be a User Interface Designer, Interaction Designer or a User Interface Architect, you need a lot more than that talent, good taste and the coolest Mac. Web applications are way more powerful that before, we have nice and powerful Javascipt libraries, Flash, Flex, Siverlight, AJAX, .NET, just to name a few, and if your designer said “Javascript? Flex? ahhh?” there is no way he can design a application exploding current technologies, making available useful features to the end user, and probably your application will look like an application from the 90’s.

I am not saying that a UI Designer needs to know every little detail about the new technologies, but  he needs to know what is possible and what is not from the technology prospective and make it part of his design, because the developer will not make that decision for him.

So, if you leading a project, please get somebody with the right UI skills, if you are a UI Designer and are/want to get into the application design, please get a little technical and help the UI Designers to get the credit than thy deserve.

Spitting Javascritp files


The growing adoption of Ajax and DHTML in web applications, have caused the creation of hundreds of open source Javascript libraries and pages have more of those than ever before plus the custom code counting thousands of lines of code in a single page load.

One of the techniques to make your application run faster is making sure you only load the necessary javascript for initialization and rendering, splitting your javascript libraries, leaving the unnecessary javascript payload to for later.

As a developers we know splitting and keeping the javascript files clean is not an easy tasks, and gets worst when multiple developers with different skill levels are modifying it, but by doing it you can get a significant faster rendering.

You can do this splitting manually by using Firebug and getting a list of functions that are executed “onload” but reading about this technique, I found Deloto. Doloto is a system developed by Microsoft Research for automatically splitting JavaScript into clusters. The first cluster contains the functions needed for initializing the web page. The remaining clusters are loaded on demand the first time the missing codeneeds to execute, or they are lazy-loaded after the initial flurry of JavaScript activity is over. When applied to Gmail, Live Maps, Redfin, MySpace, and Netflix, Doloto reduced the initial JavaScript download size by up to 50% and reduced the application load time by 20% to 40%.

I haven’t tried it yet, but it seems like a good thing to test or just to get an idea of how we can manage our javascript files to reach one of or main goals of having an application that performs as fast as possible.

If somebody have use it, it would be interesting to hear from you.

Javascript Threading? “over your dead body!”


Reading a book about Javascript performance I found this and I think is very interesting and clear the position of Brendan Eich, the creator of JavaScript and Mozilla’s chief technical officer:

You must be [as tall as an NBA player] to hack on threaded systems, and that means most programmers should run away crying. But they don’t. Instead, as with most other sharp tools, the temptation is to show how big one is by picking up the nearest singlethreaded code and jamming it into a multi-threaded embedding, or tempting racecondition fate otherwise. Occasionally the results are infamous, but too often, with only virtual fingers and limbs lost, no one learns.Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don’t scale up to handle the megacore teraflop future.
So my default answer to questions such as, “When will you add threads to JavaScript?” is: “over your dead body!”

Given Brendan’s influence in the industry and on the future of JavaScript (which is considerable), and the broad degree to which this position is shared, it is safe to say that threads will not be coming to JavaScript anytime soon.

What is fast enough? from the Usability prospective


When we are seeking for creating a responsive, high performance application, specifically on HTML/Javascript, you most of the time ask the developers to write the most efficient code and optimize to make it “as fast as possible”, but how can you know how fast is fast enough? fortunately, this evaluation was already done for us.

Jakob Nielsen is a well-known and well-regarded expert in the field of web usability; the following quote (http://www.useit.com/papers/responsetime.html) addresses the issue of “fast enough”:

The response time guidelines for web-based applications are the same as for all other applications. These guidelines have been the same for 37 years now, so they are also not likely to change with whatever implementation technology comes next.

  • 0.1 second: Limit for users feeling that they are directly manipulating objects in the UI. For example, this is the limit from the time the user selects a column in a table until that column should highlight or otherwise give feedback that it’s selected. Ideally, this wouldalso be the response time for sorting the column—if so, users would feel that they aresorting the table.
  • 1 second: Limit for users feeling that they are freely navigating the command space without having to unduly wait for the computer. A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is “working” on the command, as opposed to having the command be a direct effect of the users’ actions. Example: If sorting a table according to the selected column can’t be done in 0.1 seconds, it certainly has to be done in 1 second, or users will feel that the UI is sluggish and will lose the sense of “flow” in performing their task. For delays of more than 1 second, indicate to the user that the computer is working on the problem, for example by changing the shape of the cursor.
  • 10 seconds: Limit for users keeping their attention on the task. Anything slower than 10 seconds needs a percent-done indicator as well as a clearly signposted way for the user to interrupt the operation. Assume that users will need to reorient themselves when they return to the UI after a delay of more than 10 seconds. Delays of longer than 10 seconds are only acceptable during natural breaks in the user’s work, for example when switching tasks.

In other words, if your JavaScript code takes longer than 0.1 seconds to execute, your page won’t have that slick, snappy feel; if it takes longer than 1 second, the application feels sluggish; longer than 10 seconds, and the user will be extremely frustrated. These are the definitive guidelines to use for defining “fast enough.”

Storing Flex UI on the server.


Some time ago I face this same problem, what if we want to store some kind of Flex UI/Layout on the server, how can we do it?… even though there might be many ways, non of them are easy, so it took me some time to figure it out.

Now I have seen that many people have been trying to do the same and I want to share the idea.

For example, assume you are doing some kind of personal dashboard where the user can update the layout anyway he wants and add portlets on it, then next time he logs in we need to render it on that way and push all the portlets on the same position. Here i am going to give you and idea.

The whole concept is to store UI components on the server, you can store it anyway you want, in a table, as String, as XML, etc… then on the client you can read it and generate the UI, for example my case, I am using Java backend and RemoteObjects to transfer the data, so I have a client and server version of the components that i need to store, I have a :

-UIComponentObject.as / UIComponentObject.java

package serverobjects
{
import mx.events.IndexChangedEvent;
import mx.utils.ObjectUtil;

[Bindable]
[RemoteClass(alias="com.boardvantage.dv.domain.clientvo.UIComponentVO")]
public dynamic class UIComponentVO
{
public var width:int;
public var height:int;
public var id:String;
public var name:String;
public var type:String;
public var x:int;
public var y:int;
public var percentHeight:int;
public var percentWidth:int;

//styles
public var borderThickness:int;
public var borderStyle:String;
public var borderColor:Object;
public var cornerRadius:int;
public var backgroundColor:Object;
public var dropShadowEnabled:Boolean;
public var valign:String;
public var halign:String;

public var padding:int;

public var customStyle:Boolean;

public var url:String;

public var childs:Array= new Array();

public function UIComponentVO()
{
}

public function addChild(uiComponentVo:UIComponentVO){

addChildAt(uiComponentVo,childs.length);

}

public function addChildAt(uiComponentVo:UIComponentVO,index:int){

this.childs[index]=uiComponentVo;

}

public function getChildren():Array{

return this.childs;
}

}
}
-UIContainerObject.as/ UIContainerObject.java

package serverobjects
{
[Bindable]
[RemoteClass(alias="com.boardvantage.dv.domain.clientvo.UIContainerVO")]
public dynamic class UIContainerVO extends UIComponentVO
{
public function UIContainerVO()
{
super();
}

public var colSpan:int;
public var direction:String;
public var backgroundImage:String;
}
}

Then on the client I convert those objects to UI objects, take a look on this example:
Video
Demo

Why front-end developers are so important to the future of businesses on the web


A good friend and colleague sent me this article, and it describes very well the difficulties that a UI guy has to live with. I do agree with most of it, but also i have to add that not all the front-end developers have the skills to fulfill the position. Sometimes a developer become a front-end developer because that’s where the wave took him, bot because you like been a UI guy (developer, architect, engineer or designer). To be a good UI guy, you have to love it, its not just about the coding skills, but you have to have many other “talents”, the more he has the better. I see it like, you might be able to learn how to sing, but a singer was born with that talent, he love it and it comes natural he can definitely improve, but he has it,  as well as a good web designer was born with that good taste, common sense, good visual prospective that let him make everything look good for most of the people, or the same as a good developer was born with the ability to see functions, methods and classes as objects flying and connecting to each other on his mind. Now on this article Paul Carvill is talking about the hard to find developer that can do all that alone, there are really good ones out there, but they definitely not easy find. So i thing is very important what he say at the end:

Know your value
What does this mean if you’re a front-end or client-side web developer? Know your value. What are your skills? Are you a developer, an engineer, a User Experience architect or an Interaction Designer? Advertise your value. Shout about it. Don’t be knowingly undermined or ignored. Create a User Experience team within your business. If they’ve already got one, join it! Your job is incredibly important, and your present employer needs to realize that, as they stand to benefit.”

Programmers are generally bad at user interface design?


Today I was reading an article about UI Design, and I dont know how I ended up on this website and this guy, Nadeem Shabir is making making really good points about why generally “we think” that programmers are bad at user interface designers. Basically I share with him one point, that I explained on my previous post: Is not that programmers are not good at UI Design, at least not all of them, there might be some really good UI Designers behind those lines of code, but is just not their job to make the application look good, their job is to code it well, with nice and clean code, meeting the requirements given to them, their concentration is on the mechanics of the application, not in a UI design. I only disagree with him on one thing: I agree that they have to be taught the importance of User Interface Design and User Interaction Design, but I don’t think developers should be encouraged to learn about it, I think this is a specialized skill and even though some of them might be capable to do it, is not their job “unless” is a small project where you cant afford a UI Expert.
This work has to be done for a person that the olny concentration is and has to be making an nice and usable application without thinking about how difficult or easy its going to be, they just have to design the application based on what it is possible keeping in mind the limitations of the chosen technology. So if you are a developer and work on a small/medium size application where there is no UI designer will not hurt you to learn about UI Design and volunteer your self to do the job, I bet you, you will get noticed above the rest of the developers.

Are you a User Interface Designer?


We all know how important the User Interface Design is, technology alone will never get the user acceptance and subsequent marketability. We have to agree on this, that’s the end product, that’s what the user is going to see and they will never know what’s behind that nice or ugly screen that they have in their monitor.

We have seen a lot of good projects fail because the application is ugly, is cumbersome, is not easy to use, or usually the user claims that the previous one was better, the reason? A bad User Interface Design. Usually this happens for two reasons, one is because a lot of people do not take the UI seriously, we always hear people saying that UI Design is just picking a nice color and anybody can do that, let me tell you something, it is not. And the other reason is because the lack of real UI Designers. Some years ago when applications were just flat, plain HTML it was OK to do the design on HTML , PowerPoint or even just on a peace of paper, but not any more.

I have seen a “UI designers” that the only thing they do, is pick nice colors and use a little bit of common sense and if this is your case, its time to start looking for technology books and help to build a good looking, useful and easy to use applications, exploiting all the current technology advantages and help the UI designers the credit they deserve, instead of just keep looking at that nice, thin and cool Mac. If you think you job is just make the application look good, please change your title and go back to build good looking websites.

Building applications is not the same as building websites, when you build a website you just need your HTML editor, Photoshop or whatever you use, plus good taste, that’s it. Currently you don’t even need to know HTML, I have seen people working on UI that the only think they know is drag, drop and right click, you don’t know anything about how powerful or powerless the browser is.

Thanks to how technology has changed during the last few years, to be a User Interface Designer, Interaction Designer or a User Interface Architect, you need a lot more than that good taste, nice cloths an IPhone and the coolest Mac. Web applications are way more powerful, they are not static any more, we have AJAX, .NET, Flex, etc. and if you just said AJAX? Flex? and you dont know anything about , there is no way you can design a application exploding current technologies, making available useful features to the end user, and at the end your application will look like an application from the 80’s.

For example if you are working on an application that manages customer information, and you have to design a screen to create a customer. Before you used to talk to the customer, business analyst and user to build the persona, then create a HTML mockup, a document, then try to get the approval, etc, etc.. Then the developer would use that mockup to build the screen, there was nothing that the developer could do to mess it up, but now, let’s assume that the technology is JSF with Ajax support, where listboxes can get loaded without submitting the page, or make an Ajax call to return HTML and replace just a peace of the page, use some advance techniques to hide show content, etc. I am not saying that a UI designer needs to know how to do it, but YOU NEED TO KNOW WHAT IS POSSIBLE FROM THE TECHNOLGY PROSPECTIVE, because if you don’t make that as part of your design, believe me, the developer will not make that decision for you, do you really think a regular jsp developer will say?, “you know what? After loading the header of the Customer, I will disappear only the detail part of it and using AJAX I will bring th rest of information and hide this other one to make it user friendly ”, the answer is no, they will not do it, because they thats not their job, its yours as UI designer, you have to know how far you can reach to be able to make those decisions. Or if the application is using Flex, and you don’t define when to use, fades, transitions, effects, etc, the developer will not do it, thats why you need to know about the technology, otherwise let me tell you that your applications will be another one that we will see going down.


 

You are currently browsing the archives for the UI category.

Twitter

Categories

My Photography