Expandable Text Area

I had an issue recently where there was a standard form item, with a textInput as the entry component. The problem was that a single line was not large enough for the client to enter in the details that they required. Using a text area would be my next logical choice however because of certain real estate restrictions I wanted to keep as many form elements visible on the screen at the one time.

Hence the Expandable Text area, a hybrid of the single lined TextInput and the TextArea. Where typing and removing text would re-size the input component accordingly, and setting a text value would expand the component to cater to the text size.

It's a fairly simple component with the overridden measure method doing most of the work.

measure

Below in the measure command we utilize both the viewMetrics to determine the number or lines and then the measuredHeight of the TextArea
view plain print about
1override protected function measure():void {
2            
3    super.measure();            
4            
5    // Calculate the default size of the control based on the
6    // contents of the TextArea.text property.
7    var lineMetrics:TextLineMetrics = measureText(text);
8            
9    // get the edge metrics of the textArea
10    var vm:EdgeMetrics = viewMetrics;        
11    var w:Number = (explicitWidth - vm.left - vm.right);
12        
13    // calc the line count. If the textFields width has been
14    // updated to the TextAreas explicit
15    // height then we can use it's line count otherwise we use
16    // the lineMetrics width divided
17    // by the explicit width minus the edges
18    var lineCount:int = Math.ceil(lineMetrics.width / w);
19    
20    // use the textFields linecount if it's the layout has been initialized
21    if(useLineCount){
22        
23        lineCount = textField.numLines;
24            
25    }
26                        
27    // include the total for the line height and the
28    // padding for top bottom and leading values
29    measuredHeight = measuredMinHeight = (lineMetrics.height * lineCount)
30                    + vm.top + vm.bottom + lineMetrics.leading;
31            
32}

onTextChange

There is also a listener and handler for the "textChanged" event that is dispatched from the extended TextArea. This handler invalidates the size of the component if the number of lines in the textField has been modified. I also had to sets the variable called useLineCount to determine whether the textFields.numLines attribute should be used. As when the component is first initialized with text, the textFields layout is not yet completely set thus returning an incorrect numLines value.
view plain print about
1private function onTextChange(e:Event):void{
2                            
3    if(_prevLineCount != textField.numLines){
4                
5        // becuase the lineCount of the textField is not
6        // set as per the actual size during
7        // the first phase of instanciation we know that
8        // it's correct now so we can set a boolean to
9        // indicate that.
10        useLineCount = true;
11                
12        // invalidate the size
13        this.invalidateSize();
14                    
15        _prevLineCount = textField.numLines;
16                    
17    }
18    
19}

updateDisplayList

And the last piece is the updateDisplayList which sets the actual size of the textField based on the number of lines and the components unscaledWidth. It also sets the explicitWidth of the component if it results in a NaN. This occurs if the component's width is determined by a percentage or layout constraints.
view plain print about
1override protected function updateDisplayList(unscaledWidth:Number
2                            , unscaledHeight:Number):void{
3            
4    // we just need to layout the chrome no need for scrollbars
5    super.layoutChrome(unscaledWidth,unscaledHeight);
6            
7    // if the explicitWidth isn't set then set it.
8    // This will force the invalidateSize() to be called.
9    if(isNaN(explicitWidth)){
10                
11        explicitWidth = unscaledWidth;
12                
13    }
14            
15    var vm:EdgeMetrics = viewMetrics;
16            
17    textField.move(vm.left, vm.top);
18            
19    var w:Number = unscaledWidth - vm.left - vm.right;
20    var h:Number = unscaledHeight - vm.top - vm.bottom;
21            
22    // set the actual size of the textField based on the
23    // number of lines and the default measured minimum
24    // height of the component
25    textField.setActualSize(w
26            ,(textField.numLines) * (DEFAULT_MEASURED_MIN_HEIGHT));
27            
28}

There it is, unfortunately it's written with the Flex 3 SDK although I'll eventually port it to 4. It's a hybrid between the two text inputs which will enable the user to concentrate on data entry without having to worry about scroll bars and what they'd typed 50 characters ago.

Animating Spark List Items.

Previously in Flex 3 List Components came with a style property called the itemsChangeEffect. This allowed you to specify a sequence of effects to apply to the item renderers when a change to the dataProvider occurred.

eg.

view plain print about
1<mx:Sequence id="dataChangeEffect1">
2        <mx:Blur
3            blurYTo="12" blurXTo="12"
4            duration="300"
5            perElementOffset="150"
6            filter="removeItem"/
>

7        <mx:SetPropertyAction
8            name="visible" value="false"
9            filter="removeItem"/
>

10        <mx:UnconstrainItemAction/>
11        <mx:Parallel>
12            <mx:Move
13                duration="750"
14                easingFunction="{Elastic.easeOut}"
15                perElementOffset="20"/
>

16            <mx:RemoveItemAction
17                startDelay="400"
18                filter="removeItem"/
>

19            <mx:AddItemAction
20                startDelay="400"
21                filter="addItem"/
>

22            <mx:Blur
23                startDelay="410"
24                blurXFrom="18" blurYFrom="18" blurXTo="0" blurYTo="0"
25                duration="300"
26                filter="addItem"/
>

27        </mx:Parallel>
28    </mx:Sequence>
29
30    <!-- This TileList uses a custom data change effect. -->
31    <mx:TileList id="tlist0"
32        height="400" width="400"
33        fontSize="30" fontStyle="bold"
34        columnCount="4" rowCount="4"
35        direction="horizontal"
36        dataProvider="{myDP}"
37        allowMultipleSelection="true"
38        offscreenExtraRowsOrColumns="4"
39        itemsChangeEffect="{dataChangeEffect1}"/
>

Because I was writing a Flex 4 Application I couldn't find anything similar to this property in the Spark List components, so I decided to roll my own utilising a Custom layout for the List Component.

With the Flex 3 itemsChangeEffect you had to wait for your data to change before the effect would take place. With my effect I wanted the user to be able to drag an item around the list with the other elements moving away to allow for placement of the dragged item. Kind of like moses parting the waves with a draggable item.

Writing the custom layout:

Positioning the Elements.

Inside the custom layout it's the override of the updateDisplayList that does the hard yakka positioning and sizing the List items. It makes sure that the items x and y positions do not overlap or exceed the width of the component. In this instance the first item is in the first row and any subsequent elements are beneath this in pairs.

Drag and Drop

For this layout I still needed the the drag and drop functionality so I extended the TileLayout. If you still need the drag and drop functionality you may need to override a handful of the methods needed to calculate the dropLocations,indices and the location of the dropIndicator.

calculateDropLocation
calculateDropIndex
calculateDropCellIndex
calculateDropIndicatorBounds

Animating the elements - things to remember

With animating a Flex container you need to set the autoLayout flag to false before the animation to prevent flex from updating the containers layout after a child element is resized or repositioned. Once the animation has finished the autoLayout flag can be set back to it's default value of true.

view plain print about
1override public function updateDisplayList(width:Number, height:Number):void{
2    
3    ...
4        
5    if(animate){
6        
7        target.autoLayout = false;
8        target.validateNow();
9        
10        var trans:Parallel = new Parallel(target);    
11
12        trans.addEventListener(EffectEvent.EFFECT_END,onTransitionEnd);            
13        trans.play();
14        
15    }
16    
17}
18
19private function onTransitionEnd(e:EffectEvent):void{        
20    
21    e.target.removeEventListener(EffectEvent.EFFECT_END,onTransitionEnd);
22    target.autoLayout = true;
23    
24}

Only animate the elements that need animating. This is fairly obvious but can become a real bottleneck especially when dealing with large datasets. Test an elements previous position to determine whether it needs to be included in the sequence.

Depending on your interactivity you may need to set useVirtualLayout to false. Because virtualisation uses an estimate of elements displayed on screen for positioning and sizing, I found that with scrolling and dragging elements beyond the containers current scroll index, these elements were not being resolved. By setting it to false all elements are created and positioned allowing any calculations needed by those not currently displayed on the UI to still be allowed.

You can view and example of the layout here.

You can read more about the Spark SkinnableDataContainers here

Here is a nice article on creating custom layouts with Spark here

Mashing up Flex in Australia

I recently found out about a competition being held in Australia, by the Government 2.0 Taskforce called Mashup Australia. This taskforce, as taken from their Terms of reference.

will advise and assist the Government to:

  • make government information more accessible and usable -- to establish a pro-disclosure culture around non-sensitive public sector information;

  • make government more consultative, participatory and transparent -- to maximise the extent to which government utilises the views, knowledge and resources of the general community;

  • build a culture of online innovation within Government -- to ensure that government is receptive to the possibilities created by new collaborative technologies and uses them to advance its ambition to continually improve the way it operates;

  • promote collaboration across agencies with respect to online and information initiatives -- to ensure that efficiencies, innovations, knowledge and enthusiasm are shared on a platform of open standards;

  • identify and/or trial initiatives that may achieve or demonstrate how to accomplish the above objectives.

The Mashup Australia competition was created to emphasis this and provide a practical demonstration of the benefits of opening up sets of their data.

There was quite a large amount of data sets available albeit some not exactly in the most usable format. It was a great way to make the public aware that this data exists, and for us as developers to have fun with how this data could be presented.

I spent a few days on a couple of entries, using flex and flash for the UI. It would have been nice to have a bit more time to test them and to add a few more bells and whistles.

1.

The first idea I had was called the GCI PhotoHUB. Because a number of Government Cultural Institutions publish their photographs onto flickr I thought it would be nice to have a central application to be able to search/view these common image sets.

I used the neat as2flickrlib API however I did realise that the commons API was not included in the lib so I had to write one myself for getting that particular piece of information.

I wanted to create something that was intuitive for the end user and something a little playful for them to interact with.

This is the entry here


2.
The second idea was to create more visually digestible way to display crime statistics in Australia. I chose a number of methods for this which included primarily a map overlay, secondary - charting components, thirdly - a raw data set. I felt that this would give the end user 3 options depending on what they felt comfortable with.

The initial UI was changed slightly after working through some UX concepts from a good friend of mine who works as a UX consultant.

There were a number of design cues including the map indicators taking reference from police lights as well as the font chosen for the map overlay to help with the overall theme.

The data set provided was in the form of an xls document. Because .xls documents aren't exactly the best format for web applications. I created a webservice to read the xls file and serve up the data as both a ColdFusion query set as well as a call to return XML. Making the data much more useful for both Flex and potentially other developers eventually.

This is the entry for crimewave here

Both these apps were built in quick time so I'm sure there will be a couple of bugs crawling around :) so if you find one feel free to let me know. Overall it was a fun way to utilise this newly exposed data from the Government and even a better way to expose it using Flex as the tool.

Catalyst could save you time

I've just come back from attending the Brisbane leg of the Australian Adobe User Group. It showcased the new features and overall direction for the development suite of products which included the new Flash Catalyst, Flash Builder, Flex 4, Cold Fusion 9 and Bolt.

I was really interested in Catalyst as it's something that I could see a lot of benefit in using personally.

Adobe has made a conscious effort to further improve the work flow between designer and developer which the introduction of Catalyst.

A tool to help create interactive user interfaces transitions and all, without having to worry about a single line of code. It also enables the user to port this directly into flex for the developer to turn this into an application.

By having something like Catalyst can remove the steps involved going back and forth between Interactive Designer and Developer as the explanation of transitions and state changes are nutted out in the design stage for the developer to see. Of course this is the ideal scenario and we all know it never exactly works out as smoothly as that.

For a designer it can eliminate the need to provide multiple screen shots of piece of interaction and the need further explain your concepts through emails, phone calls, power point presentations, smoke signals or interpretive dance.

It's still in Beta so I'm sure there will be many more tantalizing features to come but so far it's looking great. Overall I can come away from the user group meeting knowing that Adobe is indeed heading in the right direction. They have identified the need to streamline the design/development work flow, as well as further enhancing an existing suite of core products.

Having said that I still think a developer that can touch type could save you more time :)

You can download the beta version of Catalyst from the Adobe Labs here

Finding UI inspiration in the everyday.

Finding inspiration in the everyday.

Often when I'm working on a certain aspect of the UI design phase for while I sometimes find analogies in everyday occurrences that I can relate back to the current UI I'm working on. It doesn't matter if it's a good or bad experience it's all part of drawing information and ideas outside the context that you're working in. I may look at it and work out how could this be improved or what makes this a good experience.

It's true with everything though, the more interest you take in something the more you notice it, and the greater the detail you notice it with.

[More]

What's behind the preloader?

What's behind the pre-loader?

CursorManager.setBusyCursor();

When designing a new UI it's important to delve inside the end user's cerebral hemispheres to understand what drives users to perform the tasks they do.

The pre-loader as a concept has been around for a long time in various forms not necessarily related to web applications. It can be seen in the form of a support act when going to see a band, or the lighting before a thunder storm, or the clowns before the lion tamer. In one way or another the pre-loader has provided a way to distract the user from the time taken to get to their main goal at that given point in time.

Adobe has obviously has understood the necessity for the pre-loader concept and have included pre-loading functionality inside the flash component library, and more recently Flex. Flex also has the capability of setting the busy cursor on service request thus emphasising the importance of notifying the user and keeping them aware that that data will appear to a screen near them. Of course this type of distraction is minimal, however providing something that is too distracting may result in a slight loss in the ability for the user to focus back on the task of interest.

I remember reading about a case study about a property owner of a large corporate building. Not a day would go past without a complaint about the building's lift and how long it took to arrive in the lobby. It came to the stage where something needed to be done about this. For the owner there were two obvious solutions, one would be to spend thousands on getting the lift replaced or let the issue go and continue being at the end of the complaint stream. An associate suggested that the owner get a psychologist in, they agreed to bring him in after much speculation. His suggestion was not to worry about replacing the lift but to fit full length mirrors in the lobby. The mirrors were installed and as a result not a single complaint was received from that point on.

In this case the mirrors were the pre-loader and the data was the lift. People were distracted by the fact that they could look at themselves while waiting for the lift (there was probably some sort of Flexing involved too). It was a very simple yet elegant solution.

Inside the flex applications that I build I like to pre-load all requests to the server whether it be as a busy cursor / text notification / progress bar or even sound (elevator music anyone?). The simplest way way I've found to do this is to have a public String property on my Model of course you may want to create a more detailed class but I'll use the string in this example. By setting this property from my commands it allows the application to listen/test to the changes to this and display the required feedback/preloader to the user.

an example would be something like this

ModelLocator.as

view plain print about
1public var statusMessage:String = "";

GetLiftCommand.as

view plain print about
1public function execute( event:CairngormEvent ):void {
2    var levelChangeEvent : LevelChangeEvent = LevelChangeEvent(event);
3    var liftID : int = levelChangeEvent.liftID;
4            
5    var delegate:LiftDelegate = new LiftDelegate(this);
6    delegate.getLift(liftID);
7    
8    /* set the service status */    
9    model.serviceStatus = "I'm getting the lift so I'll put some mirrors up";
10}
11
12public function result( event : Object ):void {
13
14    model.lift = event.result.lift;
15
16    /*clear the service status now that we've got the result*/
17    model.serviceStatus = "";
18}

MainBuilding.mxml

view plain print about
1<!-- Hide or show the mirrors based on the service status message -->
2<components:mirrors visible="{model.serviceStatus.length?true:false}" />

In todays development world where the amount of information that is being pushed back to the client is getting larger and larger, pre-loading is important to not only give feedback to the user but to give them a slight distraction prior to the data arriving.

CursorManager.removeBusyCursor();

Crumbline Navigation

Crumbline navigation has been around for a long time. The first instance I can recall was when Hansel and Gretel used a Crumbline of pebbles to navigate their way out of the forest. It was only when they used bread crumbs instead of pebbles did they become lost.

Crumblines are a great way for uses to navigate through the UI especially if the UI contains wizards and or drill downs. It provides instant feedback to the user in relation to the depth and direction of their navigational choices.

Uses can then step back to the exact position they want by selecting the specific crumb at any given time.

This is an example I created in Flex 3 to illustrate the Crumbline Navigation in it's most simplistic form.



This component takes in a collection of Crumb Objects. The Crumbline then dispatches "crumbEvents" when a crumb item is selected, letting the view dictate how it handles the navigational change.

eg.

view plain print about
1<components:Crumbline styleName="crumblineStyle" id="crumbLine" dataProvider="{acCrumbs}" crumbClick="onCrumbClick(event)" />

In this example I used a simple viewstack and bound this to the Crumbline using it's selectedIndex property.

view plain print about
1<mx:Binding source="crumbLine.selectedIndex" destination="vsChoice.selectedIndex" />

A demo of this can be seen here

Special thanks to the Brothers Grimm for the Crumbline model.

Are UI roles changing?

With the release of design based applications like Fireworks CS4 Beta from Adobe, it has again further blurred the lines between the UI professions.

Although there are other tools that can provide similar more detailed functionality that the new version of Fireworks CS4 does such as Microsoft VISIO and Omnigraffle, no other package wraps most the most common RIA Development processes in one package. Fireworks has stepped up from the shadows and has reinvented itself as a somewhat dedicated RIA Development tool. UI experts can create interactive step throughs for clients, UI wireframes, create custom components, and even export the UI Designs as MXML(flex markup) or XAML(Silverlight markup). I think Adobes decision to add these kinds of attributes to Fireworks was a great one. I always wondered what would happen to Fireworks after the merge, as it was often neglected in favor of the other Image editing tool owned by Adobe... what was the name of that one again?

I generally see UI Teams in 3 Groups

  • UX - User Experience design - They primarily look after the interaction model of the application working with concepts such as wireframes and application storyboards.
  • UI Design - They are responsible for the look and feel of the application.
  • UI Development - They are responsible for the actual coding and software development.

In small practices more often than not, a single developer is responsible for all aspects of an Application, UX, UI Design and all development both client and server. In these cases the Applications are normally built from the database up. By that I mean the backend services are written and test harnesses/wireframes created to start bringing the application together. However I can see the trend going forward in RIA development lending itself to design based/user centered development where the UI drives the design cycle of the application no matter what size the practice. And by allowing a number of client side design tools to publish working code emphasises that.

I would be interested to know how will this affect current software development cycles for teams and individuals. For those that do have resources such as usability experts how will their roles be affected? will they need retraining in current toolsets? Will graphic designers start writing and publishing MXML and XAML code?

The crossover is inevitable from UX, UI Design and UI Developer. The switch between having a UI Designer hat on and a UI Developer hat on is literally a click away.

More information about Fireworks CS4 Beta can be found here.

BlogCFC was created by Raymond Camden. This blog is running version 5.9.6.004. Contact Blog Owner