merhl

Well after trying to submitted the AIR iPhone to the Adobe AIR Market Place it didn’t agree with the Adobe Market Place terms so I renamed the app to the Desktop iPhone. Now I just gotta wait and see if Apple sends me a letter!

The app is still getting some buzz after been up for nearly a year. A recently new blog post mentions it as well as to referring to Ribbit as the phone company of the future.

I also created a new Desktop iPhone video that walks through the general functionality of the app with some voice over by yours truly.

Click on an image to see a larger version.

I just recently had the chance to really get my hands on Degrafa for a project and have seen some pretty good results. I wanted to create a small sample for some people that have yet to play with it and show some neat things like the SVG data for more complex shapes. I wanted to also show some masking in flex using mxml for some neat effects that involve some unique shapes.

The sample shows a button that is skinned with Degrafa that on rollover shows a toolTip panel. The process to create some unique shapes in Degrafa is a multi step process. You will need to take your shape into Illustrator and create a SVG file from the path, simply save the file as SVG. The Degrafa site has a nice video showing how you can do this. Using SVG Data in Degrafa

In the example you can see the top containers are transparent and can see through to the background, which is a Degrafa skin as well. So when you rollover the edit button the toolTip panel needs to be masked. So the mask is the negative of the button skin, making the toolTip panel roll down seamless.

Source - maskShape.zip

In a recent project I wanted a rollover for a ToggleButtonBar and wanted to know if it was enabled here is some sample code and a working example below.

private function toggleButtonOver(event:Event):void
			{
				var button:Button;

				if (event.target is Button)
				{
				   var index:int = toggleBar.getChildIndex((DisplayObject(event.target)));
				   button = toggleBar.getChildAt(index) as Button;
				   trace(button.enabled, button.label);

				}
			}

Source - rollOvertoggleBar.zip

I know a lot of people see prototypes as big wastes of time and money, well the way I see it is their are some great advantages. Prototyping can be a great success if done correctly and done for the right reasons. Too many times people see prototypes as the beginning of an application or the beta version of what the production application will be. Well thats not how prototypes should be treated.

The key element to a prototype is that it shows the user experience of the application, something that designs and functional documents can’t totally convey. With UX becoming such an important part of applications either on the web or desktops its going to become more and more important to show what those user experiences might be. I think clients are going to see UX as what separates their application from their competitor.

Prototypes have a variety of categories for what they could be used for.

• Getting buy in from a Board/Committee
• Creating Marketing Buzz
• User Testing
• Testing data integration and data architectural solutions
• Testing unique user interactions
• plus many others

There are some guidelines to take into consideration when building a prototype.

Prototype Life cycle
The life cycle of a prototype should have a very defining end date. The prototype should never be used as the starting point of an production application, it should only be used as a visual reference to the final production application. The code used to build rapid prototypes is just that very rapid.

Keep the focus of the prototype to just a user scenario or experience.
When building a prototype make sure to focus the efforts on a key user interaction or experience that should be defined from some sort of user scenario. For example if an application needs to display a list of items and the user needs to filter or sort them in a unique way then pick one or two of the filtering options to convey how the experience would work.

Keep the timeline short
Prototype should be something that can be built vary rapidly. A rule of thumb I try to keep my prototype under a week of development time.

A Visual Specification
When the prototype is finished it can be used as a Visual Specification for the Development/Production team to reference. This team could build the application in the any language they wish, it doesn’t have to be what the prototype was built in, unless the prototype was used for some sort of data integration testing scenario. The prototype will help define the UX for the application and the development team can concentrate on the development and reference the prototype for the UX .

Some other topics that come with Prototypes.

Interactive Prototypes
I have had people ask me about paper prototypes and how they are used vs. interactive prototype and they can see some time benefits to paper prototypes. I’d beg to differ, with the speed at which someone can build a interactive prototype’s in Flex/Air and with Thermo soon arriving is roughly the same amount of time it would take to create a paper prototype. One thing the Interactive prototype does it shows what the experience will be when a user interacts with it. Which in this case is the most powerful part of the application. Its all about conveying the experience you want to give to the user. There is a great thread about paper prototypes on IxDA.

Wireframing
Wireframing can be another step in prototyping depending on the depth and complexity of the application. I think wireframes and prototypes are something that go hand in hand that help define the user interaction and speed along the process of the building the prototype.

So if prototypes are done for the correct reasons I can see them being tremendously beneficial.