Why is it important to dedicate enough time to design your app? let me show you how we did it for Conqu, what worked, and what didn't work.

Team size and roles

I love small teams. Everybody is so much productive when the team is small. Before this project, I was in a much larger project and the change was like night and day. With a small team, where is no waste of time in long meetings, or trying to decide if feature A is better than feature B, or trying to explain to other people -that are not completely involved- what it is best or fits better in the project.

Being small is bliss, turn-arounds are quick, and in a very agile environment everybody knows what to do and we can move faster. Another thing is that you need a team that has balanced skills in UX and design, which are as important as development skills. We have three team members and each of us plays different roles.

Mark: The designer and artist. He is in charge of doing everything related to colors and pixels. In addition, he is doing some wireframe prototyping and helping us with the video, text copy and html code.

Laura: The server side development and the magic behind the ui. She is in charge of doing all ColdFusion and server side code. But because ColdFusion is so fast to write, she helps the Flex development, in special all the SQLite interaction. She also plays the role of product owner with myself.

Myself: The Flex guy. I'm in charge of doing most of the custom components on Flex and make sure that the app is optimized for mobile.

Tools

We use an internal tool, similar to Basecamp to post all the TODO's, messages and all the design files that we share with the team. Skype and IM for communication and a webdav disk for sharing assets, minimum amount of email (we prefer to have those conversations in the internal tool) and Acrobat.com for sharing documents. And last but not least, Adobe tools for development and design.

Time line

The following is a time line until today. The project is still going on, so maybe I will do another post in the future to show the progress.

Beginning & Exploration (High detailed design vs wireframe prototype)

First month - Nov 1

At this stage, only Mark worked in the project full time. In the first week, we shared ideas and made sure Mark understood what we had in mind, and what the idea behind the product was. We started with the tablet version mostly because we were exited about all the tablets (Playbook and Android) that were announced, and we didn't want to miss the boat again (we missed it for iPhone and iPad). But the true is that we are geeks and we love gadgets, so what better excuse to have a project where we would be using the latest and greatest gadget. Now that I'm looking back, maybe we should have done the Desktop version and then move to the tablets because there are many more people with desktops than tablets at this moment (I think that will soon change).

Once Mark understood what we wanted, he started working and by the end of the first week, he has his first mockup.

As you see in this design, he spent a good time in the details. He skipped the wireframe prototype and showed us a much more polished design. That is what we usually do for our clients to make them more excited and it usually works. But this time, we were the clients so we thought that maybe we didn't need that, but we were wrong. Having a more detailed design helped us visualize the final product much better, and I can tell you that one of the best experiences was when we loaded that image in a tablet for the first time. We were like children with a new toy, that image has imprinted the feeling of the experience of the app. If we had just a black and white wireframe the feeling would have been totally different.

He later did some wireframes for other parts of the application, but that process didn't last long as we learnt quickly that having a more detail design triggered more feedback in our brain. That contradicts with some of our processes that we do for clients. We usually spend a lot of time creating great Omnigraffle documents, but for this project, we had 90% of the ideas as detailed as final.

Keep in mind that that worked fine in this project but if you have a bigger team you should think about it. For bigger teams, specially when everybody wants to be the chef in the kitchen it's better to go with more iterations of wireframes until they have an agreement and then move to pixel detail. In addition, working on wireframes for the most part lets the client know that there is no actual work. Sometimes clients would see a prototype and think that we are almost done, and that is far from true.

It wasn't the case for us because the three of us have a good eye for design and UX and we can visualize quickly. We can do the wireframes over the phone in our heads and go directly to a detailed mockup. The other thing is that all of us in the team are picky, we want pixel-perfect design - all the time. Sometimes we would even agree on a wireframe, but once we had it in Photoshop (pixel-perfect), we would make a lot of adjustments. Don't get me wrong, wireframes are good but you need to do them quickly and move on because later you will change them anyway, just don't spend too much on them. That's why we ended up doing more and more final mockups and less wireframes.

The three weeks that followed were an exploration of design, where we played with different ideas until we nailed down what we wanted. Laura and I where playing the role of product owners and Mark was cranking all the designs and the only one really working.

Some of the ideas are shown in the following screen shoots, you can click to expand to full size.

From all those ideas (we have more, but I made a selection for this post) we picked what we thought worked best from each and made a final version. Mark was expecting us to choose the final one and move on. But we, the product owners, were having a hard time making the final selection, each of us were attached to different images. For example, Mark liked the black one but Laura didn't and they both liked the wood version but I didn't. We knew that we needed to get to one that all of us liked and also made sure that we had all the items in place before deciding on the final version. We knew that once we had a final version, we couldn't go back and made big changes because it would affect development badly. After a few more rounds of tweaking we got our final design. You can read more about how we chose the final design in this post.

Development starts and design expands to other areas

Second Month Dec 1

Once we were done with the design exploration, we started development. It was important that at this time we were very happy with the design that we had and we were not thinking about doing major changes in the design nor UX. Laura started working on the first screen but just part time for that month, while Mark continued working full time on the edit screen and the rest of the app. Having Mark shaping other parts of the app, helped us visualizing how the whole app would function. We then started to think about transitions and how all the different pieces would be glued together.

Development now in full speed

Third Month Jan 1

After a relaxing december, we started January at full speed, Laura and I were working on development while Mark was working on final screens of the tablet version. He finished the first iteration of the tablet version on Jan 20th. We later asked him to tweak things here and there but not big changes, mostly usability changes that we started noticing when we were using the app in a real device. We also asked him to add a settings screen that was not in the original design. Other than that, all the major things where done.

Working with all the screens ready was a pleasure. It meant non stop development not only because they were final, but also because we had all the assets ready on our webdav disk, with a picture per screen with the dimensions, fonts, drop shadow, etc that looked like this:

And this is how the vertical version looks

Continue development for tablet, design for phone and desktop were starting to take shape

Fourth Month Feb 1

Laura and I were working on the tablet and from time to time requesting small changes to Mark. Meanwhile, he started the phone version and he managed to do that plus the desktop version and the website. At this point he was multitasking with all the different things that we needed: the website for the launch, a logo, banners, tweaks on the tablet version plus the phone and desktop version. Having Mark available full time working on all this helped us move forward quickly because we always had a designer available for anything such as assets, usability issues fixes, testing and preparing the next round of development for desktop and phone.

Android and Playbook launch

Fifth Month Mar 1

We did a first launch with a Playbook version, but it was not ready for prime time. We knew it but we did it because nobody could use it anyway since the Playbook was not available at that moment. People were saying that RIM was taking a lot of time to approve the apps and we wanted to make sure that we had something on the Blackberry market as soon as possible.

Later on March 23rd, we launched the Android version for everybody to use. That was our first real milestone. A week later we updated the build for the playbook. So the whole month we worked on making an stable build with all the features that we wanted. Laura and Mark worked on submitting the apps to the different markets and preparing the images, logos, etc for each while Mark was also supporting us in the development.

Synchronization and Desktop version

Sixth Month April 1

April is not done yet as I'm writing this post, but most of the moth was spent in the synchronization and task sharing. Laura is taking care of all the ColdFusion code while I'm doing the ui. I'm done with my part and about to start the desktop version, will see how that works.

Interesting facts by numbers

Hours spent on the project

We spend 1898 hours total until today and we are still going. From that, 49% went to design. That is huge for design if you compare to other projects. Sometimes projects don't even have 5% of the total amount. The thing is that if you want to have a nice interface with good UX, you need to realize that design also takes times. Multiple iterations of design is what makes an app truly shine. Maybe 49% is too much and by the end it will be less because design started first and will finish earlier. We already have a lot of things designed that we haven't event started to develop. But I think that a 20% for design is a good number.

Design breakdown

We spend 49% of the hours in design, but what does it mean? where did we spend it the most? The following chart is not the hours on design, it is the actual number of files that we created. Some of them took longer to create than others and therefore this chart is not completely accurate, but it gives you a good idea on how much we spent on each part.

The most time was spent in the tablet because that's what we built first and it is at this moment 100% done. We expect to spend more time on other areas like desktop and phone but not as much as the tablet because we are reusing a lot of ideas.

Pixel perfect vs Wireframe

This is interesting: we spent very little in wireframe for this project, only 7%, of the design time. I mentioned before that we had our reasons and I feel that we made the right choice.

Sever side vs front end vs design

The server side is really nothing: only 5% of the whole project, and we are estimating that it will remain at the same ratio. We think that we'll need to spend more on the server side when we'll need to scale to more than one server, but for now we are not worrying too much. Flex, on the other hand, is taking much longer.

In this following chart we compare only development, between server side and UI development and the ratio is 10% vs 90%.

Flex break down

I did not talk much about Flex in this post, but let me tell you that we were very picky here as we were with the design. We built a lot of custom components. Here is the break down on Flex built-in components that we used and custom components that we built.

Conclusion

We had the idea for Conqu for long time. We even started it 3 years ago but we didn't give it the attention that it deserved. This time we approached it differently. We gave it full attention and a team of 3 people, with the same importance as any other client. This is not a project that we are doing between late nights and weekends, this is a full time project, and I feel that we did it right this time. A few other people also think the same.

I love this app! I've been searching for a simple, yet robust project/task management system and am so thankful to have found Conqu! It works great with BB PlayBook. You don't have to be well-versed in GTD to use it. I recommend checking out the website to see the new features coming soon (synchronization...YAY!). I highly recommend this awesome app!

The best part is that it is cool to work on our own ideas, not on client work. We can manage our time better, spending time were we feel that needs more work and moving quickly when we know what we want.

If you are thinking to start a new project I suggest that you do it, but don't do it half way, because your project will die in the middle. I also think it is better to delegate things that you are not capable of doing. For example, if you are a developer, try to hire a designer to help you. If you don't have the extra money, try to get a partner. If you need help with the server, you should hire someone to do that too. Of course you can do everything, but the quality of your product will be affected. Some are lucky and are both designer and devevelopers (devsigner), but they need more time to complete the whole thing so there is always a drawback.

And if you took the time to read it all please write a comment telling us what works for you. I'd love to know what things are working for others.

Follow me on twitter

It's possible that AsFusion was bitten by the app bug. Soon after releasing Conqu, we decided to create another app called OnePound. This app was smaller and less ambitious than Conqu so we were able to complete it in just a few weeks time.

OnePound is a weight tracking app for Android tablets, BlackBerry PlayBook, and the Nook. We decided to target these platforms specifically because we felt a decent app was not available in those markets.

When we set out to create OnePound, we wanted a design that was aesthetically pleasing to both men and woman, and easy to use. We didn't want to force a user to switch between data entry screens and graph screens. We didn't want users to have to change the orientation of their device to see different screens. As those types of interactions--although neat at first--get rather tiresome once you start using the app. Instead, we created OnePound to use a single screen where you can add new weights and see the chart updated instantly.

OnePound includes the most requested features for weight tracking apps: features like the ability to set a goal and track your progress along the way. It also calculates your BMI based on your height and weight automatically. You can also choose between US or metric units of measurement.

We are very excited about releasing another beautiful application into the market and look forward making more great apps just like OnePound.

One of the components that is very common in a mobile app is the Switcher component. The on/off switch is usually available on IOS and Android devices. This component is like a toggle button but with a skin that makes it look as a Switcher.

Application

This is just a simple test and we have all the styles hardcoded on it.

I have a special skin, SwitcherSkin, for the toggle button that transforms the normal toggle to a switcher.

Skin

We are extending from MobileSkin to make our skin lightweight for a mobile project. And we only have 2 elements on it: the background that has the on/off background and the thumb that moves to cover the on/off labels.

To make it more interesting, I added a little tween using the Tweener library . I hope you like it. You can improve on it making the labels dynamic and the dimensions too.

The source is available for download.

Follow me on twitter

This is part 5 of my series on item renderers. As you may know, the Mobile Flex Framework does not have a DataGrid, mostly because a DataGrid control uses a lot of real state and the phone has a small screen. But, we have tablets too and a Grid makes complete sense. However, the regular flex DataGrid will not work as it is too heavy for that. We also want gestures and bouncing like the mobile List has. So the workaround is to make an ItemRenderer that mimics a grid.

For this example I'm reusing the code of the Application from the previous Twitter example so I will not explain that. Also I'm reusing some of the pieces from the TweetRenderer but changing the layout a lot.

For reference, these are the previous posts: part 1, part 2, part 3 and part 4.

Styles

The main difference from the previous example is that I don't have individual styles for each TextField. Instead, all the fields use the same one. The new thing that I added is the vertical-grid-line-color property used to paint the vertical lines. renderers|TweetGridRenderer

TweetGridRenderer

This class has some similar elements to the TweetRenderer. The main differences are:

• I added a lineCanvas display object used to paint the vertical lines.
• I use fix height instead of variable height. The height is set by reading the value from the CSS.
• I use the same styles for all the fields. Note that we do that when we call TextUtil.createSimpleTextField and pass "this".
• I changed the layout off all the fields and removed the avatar image.

As you can see this renderer is very similar to the one on our previous example. By making just some adjustments we have a completely new layout. Hope you enjoyed this series on item Renderers.

The source is available for download.

Follow me on twitter

This is part 4 of my series on item renderers. This time we have a more real example that includes two states (selected and up) plus and avatar image and a bunch of text fields.

What I choose as the example is a TweetRenderer that shows the picture of the user, the user name and the content of the tweet.

For reference these are the previous posts: part 1, part 2, and part 3.

To simplify the code, I call the twitter service with a hardcoded value "Adobe" to receive all the tweets that include that word. As you may notice, I'm not following the best practices with services and added them in the Application file.

Styles

Now that we have more elements, our styles are growing a little bit.
We do not longer have the background-color property, because we are using images to paint the background instead. We have 2 images, one for the selected state and another for the rest (in this case we have only one, the up state). We use the pseudo selectors to target the different states but in both cases the name of the property is "background".

Other thing that we have now is individual style classes for the different text fields of the renderer. We have one for the name, one for the username and another for the content.

Renderer

Because we want change the background when the user clicks in the item we need to implement the interface IItemRenderer, that allow the List to notify the renderers every time the selection changes. The help us with that task we create another class, the BaseRenderer that takes cares of the implementation of that interface and the TweetRenderer extends from it.

I added 2 methods to this base class: setValues which is called every time that the data changes and updateSkin which is called every time that the selection changes.

In the method updateSkin that is implemented in the TweetRenderer we change the state of the skin. Changing the state gives us new values for our call to the getStyle method. For example, when we change to the "selected" state and we call getStyle( "background" ) we get the image that is defined inside the pseudo selector TweetRenderer:selected. When we are in the "up" state, we get the default value for the background property. All this CSS functionally is provided by extending StyleClient.

You can see that in the following code

We also have now more children to create and layout. We have an image to load for the avatar, the embedded images for the background and a bunch of text fields. For the text fields, we use the same TextUtil to help us on the task of reading the styles and setting the properties. You may notice that we have 3 different styles, one for each text field. The TextUtil can read the styles from a class or from the type selector or current object ("this"). In this case we use 3 different classes.

The other thing that I implemented in this renderer is the ability to have variable height. To make it work with the list I just override the method getLayoutBoundsHeight that returns the height of the renderer after the layout is done. The List will use that value to layout all the items one after the other even if the height is different for each renderer.

The source is available for download.

Follow me on twitter

This is Part 3 of the series "Mobile ItemRenderer in ActionScript". This time we are going to use a different option to add the drop shadows to the text. We will be using a filter instead of having an extra text field.

Part 1 and Part 2 for reference.

Drop shadow Filter vs a second TextField

The second text field workaround is good and performs better, but sometimes the designer has a bigger and softer shadow that cannot be reproduced with this technique. In that case we need to use a filter or bring a whole image from an image editor like Photoshop. Having an image works only if your text is not dynamic but lists usually have dynamic data. In that case, we don't have another option than to use a filter. From my experience of running an app in different devices, I found that the filters do not perform that bad, specially in tablets which have good memory and processor. You should test and see it how performs for you and maybe you can optimize in another places instead.

Styles

SpriteLabel Renderer

This class is simpler that the one that we used in our previous example because now we don't need to deal with 2 text fields. One interesting thing that I added this time is text truncation. Truncating the label is something useful that you will need in your renderers when they have long text.
The TextUtil class provides a handy method to truncate the TextFiled. I hardcoded the width to 180px so you can see how it gets truncated.

The TextUtil also takes care of the drop shadow because the values for the drop shadow are coming from the CSS and we are delegating that task to the TextUtil. The filter is added by TextUtil with the help of another class.

Here it is the snippet of the code on the TextUtil that does that. The rest of the class has no changes from our previous post.

CSSDropShadowFilter

This class is in charge of creating a drop shadow filter from an Array. The array is coming directly from the CSS. It supports all the possible values that the drop shadow filter support. The only catch is that you need to pass all the parameters in the CSS in the same order of the constructor of the DropShadowFilter, which are: distance, angle,color, alpha, blurX, blurY, strength, quality, inner, knockout, and hideObject.
You can pass one or as many as you want, you just need to keep the order.

Continue reading Part 4 of this series on Item Renderers

The source is available for download.

Follow me on twitter

This is Part 2 of my series "Mobile ItemRenderers in ActionScript". This time I will explore how to apply drop shadows using a second TextField.

You can find part 1 here for reference

Why do we use a second TextField?

As many of you may know, it is not recommended to use filters like drop shadow, bevel, or others on a DisplayObject when you are developing for Mobile. This is mostly because the player needs to create an extra image for each object that has a filter and that can bring performance issues. So if we want a text field with some drop shadow, the workaround is to have a second text field under it and move it a pixel down to mimic the effect.

Styles

I have a text-drop-shadow-color property to pass the color of the shadow to the renderer. We also have a background-color style to have some contrast and be able to see the shadow. The rest is very similar to our previous example.

SpriteVisualElement vs UIComponent

In the previous example, we were extending from UIComponent. This time we are getting rid of UIComponent and using a more light weight component. The problem is that the List needs an IVisualElement and because of that, we are extending from SpriteVisualElement (Note: you can implement the IVisualElement interface and not use the SpriteVisualElement at all).

The other problem that we have now is that the SpriteVisualElement is not as complete as the UIComponent. We are missing something that the UIComponent provided us: CSS support. To fix that I created a simple class called StyleClient that implements the IStyleClient and allows the component to participate in the styling framework. In addition to that, this class includes the measure, createChildren and updateDisplayList in a similar way as the UIComponet (but much simpler). With that we can change the inheritance from UIComponent to StyleClient. The swap between classes can be made because some of the methods of UIComponent are supported in the StyleClient.

One thing that's important to mention is that the StyleClient does not wait for the next frame to commit the properties or invalidate. If that is needed, it is not really hard to implement. You can see the inheritance chain of our renderers in the picture below.

I'm not going to paste all the code of the StyleClient, because this class is basically the implementation of the IStyleClient interface (with the exception of registerEffects that I didn't feel that I needed). I want to highlight a few things though: first, notice that the method setLayoutBoundsSize calls updateDisplayList internally because this is the method that the List will use to layout the renderers.

Second, we call measure and createChildren once all the styles are ready in stylesInitialized, to make sure that all the assets that we need for the renderer that are coming from the CSS are available.

SpriteShadowLabel Renderer

Let's take a look at the Renderer now. I'm reusing some of the code from the previous example: the data setter, the measure method and the constructor are very similar. The difference is that the data setter calls setValues if the TextFields are already created.

The other 3 methods for this class are:

• createChildren where we create both TextFields and we delegate the task of creation and reading the styles to the TextUtil (more on that later).
• updateDisplayList we layout both TextFields and draw the background and separator.
• setValues sets the data to both TextFields.

TextUtil

This helper class creates a TextField and sets all the styles (bold, italic, font family, etc) and a couple of properties like autoSize and selectable in the new TextField been created. All the styles for the text fields are coming from CSS, from a class selector example: .myClass or from a type selector example: MyItemRender.

Continue reading Part 3 of this series on Item Renderers

The source is available for download.

Follow me on twitter

If you are starting to do mobile development and are used to create all your ItemRenderers in MXML, you may notice that the small devices like phones and tablets do not perform as well as the desktop does and you need to start looking closely to different ways to optimize you app.

One of the ways to optimize your mobile app is to create your ItemRenderers in ActionScript. Narciso Jaramillo wrote a good article for Devnet with great tips for mobile development and one of the items was exactly that, to keep your ItemRenderers in pure ActionScript.

Narciso mentions the Flex Framework comes with two ItemRenderers one is LabelItemRenderer that extends UIComponent and the other is IconItemRenderer that extends LabelItemRenderer. Those classes are great, but sometimes you have a different use case that needs a different set of classes. So in my examples I will not use those renderers. Instead, I will extend from UIComponent directly or from SpriteVisualElement for an even more lightweight class than UIComponent.

For the purpose of this tutorial, I'm planning a series of posts explaining the basics and moving on to more difficult renderers.

Basic Example

Let's start with the most simple renderer, a TextField that displays some text. To make it simple, we will extend from UIComponent and implement the IDataRenderer interface required from the List.

But before talking about the renderer, let's talk about the other elements.

Application

You need to create a Mobile project. In this example, I use the simplest of all root containers, that is an Application, not the TabbedApplication nor ViewBasedApplication subclasses. I added a List that expands 100% as the only element.

Styles

I added an external StyleSheet where I have all the styles for the ItemRenderer:

ItemRenderer

I have a simple class extending UIComponet that gives me a few handy methods and the ability to participate in the CSS framework.

The 3 methods from UIComponent that we use are the following:

• measure where we read the min size of the renderer from the style sheet. That comes in handy because devices with different dpi resolutions need different sizes.
• createChildren where we create the TextField, set the styles and if there is the data already available, we set the text in the TextField to be displayed.
• updateDisplayList where we layout the elements and we draw a line separator for each ItemRenderer.

In additions to those methods, we have the data property, which is the implementation of the IDataRenderer interface. That interface is the contract with the List and it is the way that the data is pushed to the ItemRenderer. If the TextField exists at the moment when the data is set, we set the text on the TextField, otherwise, we save it for later.

As you can see writing an ItemRenderer in ActionScript is not as difficult as it sounds.
I'm planning to show other examples in the future with multiple elements, background, states, text manipulation, multiple columns and more.

Continue reading Part 2 of this series on Item Renderers

The source is available for download.

Follow me on twitter

...when running your app on a small, high screen-density device.

As you may know, we are developing a GTD application that runs on the Blackberry Playbook and Android tablets (others to come) called Conqu. When we started, back in November, we were making designs as normal with Photoshop at the right size, and what we liked the most when looking at the designs (even when made small to fit the size of the device) were usually not all that good on the device. Since we hadn't developed the app yet, we only had mockup images to see. So what we did was browse those images to see how the actual app would look like.

This is what we learned:

You need more contrast than you think

While looking at the designs on the desktop monitor, bold and contrasting designs looked kind of ugly. They looked overdone. Not so on the device. The more contrast the elements had, the better they looked, the easier was to find them, the more defined were the different parts of the application, such as menus or navigation bars. Clearly defined elements were much needed than on the desktop. People using your app may be waiting for the bus under the sun, the screen may have glare, or they may have it sitting on their desk flat, so the viewing angle might not be optimal. Design for not-optimal viewing conditions.

Compare these two selected item designs for the menu:

Very little contrast.

A lot of contrast. While the first one might work on the web or desktop, the second was better for a handheld device. This design also has larger font, making it easier to read.

Subtleties get lost

While designing, we liked subtle shadows, soft colors and small details. However, on the device, soft gradients, small changes in tone or color were almost completely lost. Thin lines almost disappeared and elements we not clearly defined when there was not enough contrast. What's interesting is that "enough contrast" is actually "a lot" of contrast in a regular design (see point number one). You need detail, otherwise the application will look flat and uninteresting, but don't rely on subtleties for important things. For example, if you want to mark an item in a list as selected, make sure there is enough difference in color or texture, and not just some subtle shadow or change in tone. You also have to think about how far from the device your user will be. For a phone, people tend to look closer to it, so you can get away with small fonts and small details, but with a tablet, they may have it in their lap on the couch, so their eyes might be not as close to the device, so you would need larger fonts, more contrast, etc. 

Subtle lines. Overdue date is only shown with a nice glowy red box.

More contrasting lines. The overdue date is shown with a "pill" to make it clearer. The checkbox is also red, but it is not the sole indicator.

The device has its own boundaries

Unlike a big desktop monitor these devices have boundaries (physical boundaries, the bezel) that you immediately see. While desktop applications can be full screen, they are generally enclosed in a window chrome, which can be "floating" around among other applications and you may even see your desktop wallpaper as background. In a device, however, your app will be full screen and will interact with the bezel and the device boundaries. The edges are important and elements that fit directly on the edges looked better than those that have space around them close to the edge. So in my opinion, the first menu looked better than the second one, as it used the device itself as an edge. This worked better on a smaller device (Galaxy Tab), but it may not necessarily be better on a larger device such as the iPad or Motorola XOOM. In those bigger displays, you may need additional borders so that the app doesn't look like is falling out the edge. 

This design had a big border around the menu.

This design is snapping to the border of the device, utilizing the bezel as the sourounding box. It felt better than the previous one.

Speaking about the XOOM, or rather about Honeycomb, you have to remember that Honeycomb tablets have three buttons on the lower left edge. Unfortunately, that was the same placement for our lower four menu items. The issue here is that we no longer had a smooth edge and extra controls were added to that edge.

The arrow shows the stacked menus (ours and Honeycomb's at the bottom)

Test and test some more

Devices can differ in size and screen density, the operating system may add controls, or a status bar and you need to make sure the design will work on those environments. Make sure you always check your designs in at least a couple of devices.

So maybe not all you know is wrong. Just take into account those points above as a reference since design is so subjective anyway (not even our designer Mark completely agrees with everything I said).

The idea for Conqu was hashed long before the Android or Blackberry tablets were even a rumor. However, the idea sat on the back burner for several years until finally the first production tablet devices were on demo at Adobe MAX in late 2010. At that point the hardware finally caught up to the requirements of such an app. It was time to un-shelf the idea and put forth the effort to create an exceptional app for the Blackberry Playbook.

ASFusion has a history of developing some really nice apps Adobe Flex and Air, so the fit seemed natural. In November we started creating wireframes and mockups for the Conqu interface, only we had a few challenges to overcome. First, documentation was scarce. Having never developed a tablet or a touch based app before, we had to do a lot of learning, and a lot of idea testing and iterations on mockups.

After a disappointing realization that the original application name "Flow" was already being used by another company building--ironically a similar application--the name was changed to Conqu as a reference to "Conquer" in the phrase "Conquer your inbox".

Unique Challenges

On the development side, we had to overcome some unique programming challenges. For instance, buttons and graphics for most apps can be made flexible through the use of a technique called Scale Nine. What Scale Nine does is slice a graphic into nine parts so they can be stretched across the middle areas to accommodate any content size. The challenge we faced is that our interface was far more complex having gradients, top lighting for realism, and a texture that is impossible to stretch. 

This need to use textures in the interface meant that we had to come up with a new technique. This led us to develop a method for using a hybrid Scale Nine that allowed us the flexibility to tile the middle part of a graphic to make it accept the content as needed.

The Result

We feel pretty good about the upcoming release of Conqu on both the Playbook and the Android platform. We think that the public will appreciate the fine details in the design as well as the many powerful features that make up Conqu. Conqu a great demonstration of what ASFusion is capable of producing no mater what the challenges are.

At MAX we were shown, in a glass case, the new Blackberry Playbook. I am personally super excited to try it out and start developing for it. First, you build apps for it using Flash (pure ActionScript or MXML), second, their store will be free (at least for some introductory time) and third, the hardware specs makes it the best on the market (1 GB RAM and 1 GHz dual-core processor??). Interestingly, their first development platform for it is Flash, and they said that later they will allow you to use Java and C++, so you can imagine that at this moment, Flash is as good as native.

And there is more. If you develop an application before the Playbook's launch and it gets approved, you'll be able to get a free Playbook from RIM. The launch date is not yet announced, but I would get started as quickly as I can.

There are weekly webcast series you can attend. Those are hosted by RIM and usually Renaun Erickson from Adobe also shows relevant ActionScript code. They are a good starting point. You can find the link to those, the Getting Started guide and the documentation at the BlackBerry Tablet OS Development Resources. 

What are you waiting for?

Hello everyone, I wanted to introduce myself as the newest member to join the ranks of ASFusion. I was hired on November 1st as a designer and front end developer, and I am excited to work with a team of people that really understand how the web works, and has a good sense of how to make the impossible happen.

About me: my name is Mark Aplet. If your familiar with Mango Blog, then you may have already heard my name before--or perhaps my username (visual28)--I design and develop themes or "skins" for Mango Blog users to dress up their blogs. I have also developed a number of free plugins for mango blog that are available from my personal website. I have been fairly active in the Mango Blog community since I was introduced to it about two and a half years ago. So if you have a theming question, I am a pretty good person to ask.

I have been working in the design industry for about 10 years. Then specifically in web design for about 7 plus years. In that time I have taught myself html and css, and even a little ColdFusion. In fact my very first ColdFusion app was MyCFNuke (no longer available). The ColdFusion clone of PHPNuke. I don't conceder myself to be a ColdFusion programmer in the least. I know my way around CF, but feel more at home in HTML and CSS. Languages that I hope will be put to good use while employed here at ASFusion.

When I am not designing or developing websites, I enjoy getting out of the house with my wife (BFF) and or family pet Henna--a very energetic golden retriever--for a trip up to the mountains for some camping, fun in the snow, or an all out off-road adventure in a heavily modified 1942 Jeep rockcrawler.

A couple of weeks ago, Adobe launched an AIR application called Adobe Enterprise Cafe:

The Adobe Enterprise Café AIR app helps you stay in touch with Adobe teams and the enterprise community, receive news, find information, and aggregate content related to the entire enterprise community knowledge base. This is great place for all partners to receive timely news and stayed informed.

I am happy to say that we developed the news section of the application in Flex using the Mate Framework, and its backend, which is powered by Mango Blog. 

A couple of development details

While developing it, we made sure that the skin was exactly the same as the original design, to the pixel detail, leaving very little of the default Flex skin. This required creating a couple of custom components, such as the scrolling list and news next/previous navigation. 

The smooth scrolling list will always keep the currently selected item on view when switching items, so if you scroll and then move to the next or previous item, it will quickly scroll to that position. 

Backend

The news are fed by a Mango Blog install. We developed a couple of plugins to rate the posts, move old posts to the archives, get Adobe.tv video URLs, get top posts, and more. Thumbnails, product (LiveCycle, Acrobat, ColdFusion, etc) and links are managed by custom fields, and all of the custom fields are shown in a user-friendly “custom panel”. All communication is done via Remoting.

Install the app

2010 brought a lot of changes to us and a big move. In December last year, the lease for our old office expired and we thought that we could change the scenery too. So we decided to go back to Los Angeles, after several years living in the Orange County. 

With this change, I also needed to resign my title as the Manager of the OCFlex user group. But I have become an Adobe Community Professional, so I will still be involved with the community. 

These are some photos of our old office, which I really liked!

And some of our new office:

This year I was part of the advisory board for the RIA track of CF.Objective(). I was also invited to speak. For the record, I didn’t submit or vote for my session. :) Even though it must have become a little difficult to manage all the people in the board (3 members per track), it allowed for democratic voting of topics and wider variety. It was pretty amazing to see how people’s interests lined up. 

Overall, they had a good mix of topics, mostly advanced, which is a very good thing. From my experience at 360|Flex, people love in-depth topics. I believe CF.Objective gets the brightest CF audience, so it does make sense to have mostly advanced topics. 

Unfortunately, the Flex part of the RIA track had very little attendance. There were only 5 Flex-only topics, and they were placed on the last day, which is always hard. I don’t think the RIA track did all that bad overall, as the JavaScript and AIR sessions had good attendance. 

From the speaker perspective, I think CF.Objective is one of the best conferences. They pay for speakers hotel rooms and even for the shuttle from the airport. This is a small gesture that really relieves the speakers of the burden of finding the correct transportation. You just go to Super Shuttle’s desk and ask for your ticket. Minutes later you are routed to the right hotel without having to even find the address. 

The hotel is very good, and they even serve organic eggs for breakfast! It has a good bar where you can actually have conversations since it is not loud. The hotel is located in Downtown Minneapolis instead of some isolated location, so you can always walk to get  anything you need or find good restaurants all around. The food they served at the conference was great, and they had fulfilling vegan options. Other conferences I've been to, their version of a vegetarian option is - if they actually have one - 3 pieces of lettuce on a wrap.

During the Bird of a Feather sessions they had a Pecha Kucha, which was pretty fun and interesting. I have to say that I was pretty surprised by some of the speakers, particularly Ben Nadel and Anthony Israel-Davis. I wish I could find the videos people recorded. 

Overall, it was a great conference and I was very happy to see a lot of friendly faces I only get to see once a year.