EffectiveUI Blog

Most people would agree that building a software app is a much different undertaking than, say, building a bridge. Yet, there is one thing you can count on in both cases: change. Change can come from within the project as opportunities, risks and issues are encountered. It can also come from outside the project as the priorities of stakeholders shift.

In the latter case, however well intentioned or valuable, change demanded by stakeholders can be especially difficult when it comes to software development projects. Just for fun, let’s consider the type of stakeholder requests that a bridge builder would never have to worry about fielding midway through the construction process…

- Our CEO just read an article about how a cantilever bridge collapsed in Quebec in 1907, so he’s worried about risks you failed to tell us about. Please change the bridge design from cantilever to suspension.

- We aren’t very happy with how the bridge looks so far. Can you propose a change in the kind of materials you’re using to make it more attractive?

- Can we move the bridge 17 feet to the left? It’s only 17 feet, so that’s not a big deal, right?

- The natural gas pipeline that we ran under the bridge without telling you just exploded and partially destroyed the bridge. Why didn’t you build it to withstand explosions? Please fix the damage and give it proper reinforcement, coordinate with our gas pipeline vendor, and have everything done within the original timeline and budget.

- Remember when you asked us whether the bridge would ever need to support vehicle traffic and not just pedestrian traffic, and we weren’t sure, so we just settled on the cheaper pedestrian version? Well, we were wrong. What can you do to make this work for our needs?

- My nephew is majoring in civil engineering and he says the best, most advanced kind of bridge is a side-spar cable-stayed suspension bridge. I don’t really know what that means, but why aren’t we getting the most advanced bridge possible?

- We’ve hired an offshore company to start building from the other side of the valley so we can cut the construction time in half. They’re making some improvements on your design, so please coordinate with them to make sure everything comes together ahead of schedule.

In software, scarcely a week goes by without some comparable request coming from stakeholders. Because most people don’t understand how software is built and because it has no material, tangible presence, they don’t have any basis for understanding what is hard and what is easy. It’s obvious that moving a bridge 17 feet to the left is an enormous undertaking, but a comparable change in software can be appreciated only by those building it.

So what’s a software project manager to do? The logical approach is to explain to stakeholders why their request may be difficult to accommodate or explore the ramifications of the changes they are asking for (increased costs, competing goals, schedule delays, etc.). Logic, however, can easily be trumped by subjectivity – that internal filter each person has that enables ten of us to observe the same bank robbery and relay ten different accounts of the event to the police.

It’s the same with software — people pick up on different features and nuances when they look at or use an application. Unlike a bridge — which can be considered a success if it fulfills the original design, spans the intended gap, and withstands reasonable stressors — software is often judged with much more subjective criteria by stakeholders. If the final product accomplishes 99 out of 100 goals, but the one missing goal was the pet feature of a key stakeholder, you may have failed.

The secret to success is to take control of and manage your stakeholders’ expectations. We’ll look at a few ways to accomplish this tricky task in part two of this post.

Note: Portions of this blog were excerpted from the book, “Effective UI: The Art of Building Great User Experience in Software.”

Forrester recently posted a question to its Customer Experience Community members on what their major predictions were around the customer experience in 2012. There was a lot of discussion around organizational maturity (e.g., is the organization in a place where it can take on a true customer focus?), as well as the personalization of experiences across channels. I chimed in with some thoughts on what we can expect next year with regard to the digital experience, and I wanted to share my thoughts here as well.

From a digital perspective, I agree with these trends, but I also think that customer understanding is going to be key. EffectiveUI’s clients have shown an increased appetite to take the time and go through the process of truly understanding their customers through ethnographic research, and we expect to see even more of this in 2012. Specific to the digital experience, and with companies rushing to mobile as a customer touch point, it will become even more important for companies to understand customers in the context of their environments, using social research methods such as contextual inquiry and digital diary studies.

With regard to mobile, 2011 was definitely an app-happy year. I anticipate that in 2012, we’ll see more companies looking at a holistic mobile strategy, instead of just getting apps in the store. I think many companies will be more educated on when and how to leverage native functionality to meet their business and customer needs versus leveraging a mobile web solution. Most importantly, they will be thinking about a more holistic plan that weighs out scalability, ubiquity and efficiency along with usability, usefulness and engagement (great UX)!

Furthermore, customers are increasingly coming to expect great customer service, while companies are struggling to reduce costs without impacting service levels. In order to do this, organizations will need to look to digital even more to create positive service experiences and fulfill on their brand promise without driving up costs.

On this note, we’ll probably also see companies start to think more about their digital channels as part of their overall customer experience, instead of only marketing campaigns and websites. Digital will become more important in customer loyalty and retention in addition to acquisition. Because of this, the design of a company’s digital properties will need to be more than just visual; they will need to have utility, helping people accomplish tasks and solve problems, be more efficient and enhance their daily routines. We’ve seen this quite a bit in the financial services sector, and we expect other industries to follow suit.

All in all, 2011 has been a great year for customer and user experience, and I’m looking forward to a new year of great experiences. All of us at EffectiveUI wish you and yours a happy and prosperous 2012!

I’ve been a fan of Smashing Magazine for some time, so when I was asked to write an article for them you can imagine my excitement. We decided the piece should focus on some of our user research methodologies, especially those explored in EffectiveUI’s project with Boeing.

There were several key deliverables provided to Boeing that helped overcome some of the traditional obstacles we normally face. Among these was a new categorization of personas, as well as delivering customer journey maps, both discussed in detail in the Smashing Magazine article. We also provided best practices for how to communicate findings to a client for optimal results.

Interest curves help set the pace of a presentation

I hope the article is helpful for other UX teams. Let me know what you think!

Read Now: Effective User Research And Transforming The Minds Of Clients

This article is part of a 3-part series on how to build a simple painting app for different mobile platforms. The aim is to explain to readers how a simple programming concept has to evolve to create a good user experience with high performance. The series is available for iOS, Android, as well as Adobe AIR for mobile.

The Naive Approach to Painting in iOS

The starting approach to painting on iOS is to simply capture touch events and draw a line between the points. We can create and attach a custom UIView to the root view controller to handle all this functionality.

// in our root view controller
- (void)viewDidLoad {
    [super viewDidLoad];
    PaintView *paint = [[PaintView alloc] initWithFrame:self.view.bounds];
    [self.view addSubview:paint];
    [paint release];
}

// PaintView.m
@implementation PaintView

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        hue = 0.0;
    }
    return self;
}

- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
    touch = [touches anyObject];
    [self setNeedsDisplay];
}

- (void)drawRect:(CGRect)rect {
    if(touch != nil){
        CGContextRef context = UIGraphicsGetCurrentContext();

        hue += 0.005;
        if(hue > 1.0) hue = 0.0;
        UIColor *color = [UIColor colorWithHue:hue saturation:0.7 brightness:1.0 alpha:1.0];

        CGContextSetStrokeColorWithColor(context, [color CGColor]);
        CGContextSetLineCap(context, kCGLineCapRound);
        CGContextSetLineWidth(context, 15);

        CGPoint lastPoint = [touch previousLocationInView:self];
        CGPoint newPoint = [touch locationInView:self];

        CGContextMoveToPoint(context, lastPoint.x, lastPoint.y);
        CGContextAddLineToPoint(context, newPoint.x, newPoint.y);
        CGContextStrokePath(context);
    }
}

@end

The code is very straightforward and appears to do exactly what we want. When a touch is captured, we save the touch object and ask the screen to update its display which will call (void)drawRect to draw a new segment of line. Unfortunately when you run the code you’ll see a big problem with this solution. The painting will flicker as you draw your finger along the screen.

The reason this happens is that the render engine is double buffered, so each time you issue a call to draw a line segment, it tick-tocks between the two buffers. Our naive attempt to draw to the screen needs a new solution to work properly.

Next Step: Adding in a Backing Store

The way to solve this problem is to draw to a backing store first, then when we want to update the screen we simply draw that backing store to the front buffer. To handle the backing store we need to create a new cgcontext tied to a bitmap.

@implementation PaintView

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        hue = 0.0;
        [self initContext:frame.size];
    }
    return self;
}

- (BOOL) initContext:(CGSize)size {

	int bitmapByteCount;
	int	bitmapBytesPerRow;

	// Declare the number of bytes per row. Each pixel in the bitmap in this
	// example is represented by 4 bytes; 8 bits each of red, green, blue, and
	// alpha.
	bitmapBytesPerRow = (size.width * 4);
	bitmapByteCount = (bitmapBytesPerRow * size.height);

	// Allocate memory for image data. This is the destination in memory
	// where any drawing to the bitmap context will be rendered.
	cacheBitmap = malloc( bitmapByteCount );
	if (cacheBitmap == NULL){
		return NO;
	}
	cacheContext = CGBitmapContextCreate (cacheBitmap, size.width, size.height, 8, bitmapBytesPerRow, CGColorSpaceCreateDeviceRGB(), kCGImageAlphaNoneSkipFirst);
	return YES;
}

- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
    UITouch *touch = [touches anyObject];
    [self drawToCache:touch];
}

- (void) drawToCache:(UITouch*)touch {
    hue += 0.005;
    if(hue > 1.0) hue = 0.0;
    UIColor *color = [UIColor colorWithHue:hue saturation:0.7 brightness:1.0 alpha:1.0];

    CGContextSetStrokeColorWithColor(cacheContext, [color CGColor]);
    CGContextSetLineCap(cacheContext, kCGLineCapRound);
    CGContextSetLineWidth(cacheContext, 15);

    CGPoint lastPoint = [touch previousLocationInView:self];
    CGPoint newPoint = [touch locationInView:self];

    CGContextMoveToPoint(cacheContext, lastPoint.x, lastPoint.y);
    CGContextAddLineToPoint(cacheContext, newPoint.x, newPoint.y);
    CGContextStrokePath(cacheContext);
    [self setNeedsDisplay];
}

- (void) drawRect:(CGRect)rect {
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGImageRef cacheImage = CGBitmapContextCreateImage(cacheContext);
    CGContextDrawImage(context, self.bounds, cacheImage);
    CGImageRelease(cacheImage);
}

@end

When the view is created we create a cached bitmap and cached context to handle all of our touch drawing, then in our drawRect callback we now grab a image snapshot of the cached context to draw to the front buffer. The full drawing is now shown every time you move your finger around the display.

Next Step: Optimizing the Drawing Code

At this point we have a working solution, but we don’t have a good solution. Depending on the hardware you run this on, you may notice that the drawing is having a hard time keeping up with your finger. The reason why is because we’re wasting a lot of time updating areas of the screen that aren’t changing, we’re simply rendering everything in the backing store 50 to 60 times per second. To solve this we want to tell the draw routine to only update the parts of the display that have changed. To do this we create a bounding box around the line being drawn and pass that box on to the drawRect routine.

- (void) drawToCache:(UITouch*)touch {
    hue += 0.005;
    if(hue > 1.0) hue = 0.0;
    UIColor *color = [UIColor colorWithHue:hue saturation:0.7 brightness:1.0 alpha:1.0];

    CGContextSetStrokeColorWithColor(cacheContext, [color CGColor]);
    CGContextSetLineCap(cacheContext, kCGLineCapRound);
    CGContextSetLineWidth(cacheContext, 15);

    CGPoint lastPoint = [touch previousLocationInView:self];
    CGPoint newPoint = [touch locationInView:self];

    CGContextMoveToPoint(cacheContext, lastPoint.x, lastPoint.y);
    CGContextAddLineToPoint(cacheContext, newPoint.x, newPoint.y);
    CGContextStrokePath(cacheContext);

    CGRect dirtyPoint1 = CGRectMake(lastPoint.x-10, lastPoint.y-10, 20, 20);
    CGRect dirtyPoint2 = CGRectMake(newPoint.x-10, newPoint.y-10, 20, 20);
    [self setNeedsDisplayInRect:CGRectUnion(dirtyPoint1, dirtyPoint2)];
}

We now have a bounding box around our touch points that includes a bit of padding to accommodate the line width. At this point we have a very simple yet high performance painting app. For many people this may be the last step needed to understand how to build a general painting app. However, there a few more concepts we can dive into to make the app better.

Creating smooth lines

If you run the app you’ll likely notice that all of the lines being drawn are very jagged. This is because we’re simply drawing straight lines between each touch point. Since touch events only fire about 50 times per second we need to use some interpolation to smooth out the lines in between those touch points.

We can solve this problem using bezier curves, but it comes at a cost. In order to know where to curve our lines to, we always need to calculate curves one frame behind the current touch point. In the example below you can see that the curve between touch 1 and touch 2 isn’t known until touch 3 is provided.

To create clean continuous lines we ultimately want to track a total of 4 touch points in order to create our control points for the line. I’m using the formula available at http://www.antigrain.com/research/bezier_interpolation/ to determine those control points, and feeding it into the code below.

- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    UITouch *touch = [touches anyObject];
    point0 = CGPointMake(-1, -1);
    point1 = CGPointMake(-1, -1); // previous previous point
    point2 = CGPointMake(-1, -1); // previous touch point
    point3 = [touch locationInView:self]; // current touch point
}

- (void) touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event {
    UITouch *touch = [touches anyObject];
    point0 = point1;
    point1 = point2;
    point2 = point3;
    point3 = [touch locationInView:self];
    [self drawToCache];
}

- (void) drawToCache {
    if(point1.x > -1){
        hue += 0.005;
        if(hue > 1.0) hue = 0.0;
        UIColor *color = [UIColor colorWithHue:hue saturation:0.7 brightness:1.0 alpha:1.0];

        CGContextSetStrokeColorWithColor(cacheContext, [color CGColor]);
        CGContextSetLineCap(cacheContext, kCGLineCapRound);
        CGContextSetLineWidth(cacheContext, 15);

        double x0 = (point0.x > -1) ? point0.x : point1.x; //after 4 touches we should have a back anchor point, if not, use the current anchor point
        double y0 = (point0.y > -1) ? point0.y : point1.y; //after 4 touches we should have a back anchor point, if not, use the current anchor point
        double x1 = point1.x;
        double y1 = point1.y;
        double x2 = point2.x;
        double y2 = point2.y;
        double x3 = point3.x;
        double y3 = point3.y;

        double xc1 = (x0 + x1) / 2.0;
        double yc1 = (y0 + y1) / 2.0;
        double xc2 = (x1 + x2) / 2.0;
        double yc2 = (y1 + y2) / 2.0;
        double xc3 = (x2 + x3) / 2.0;
        double yc3 = (y2 + y3) / 2.0;

        double len1 = sqrt((x1-x0) * (x1-x0) + (y1-y0) * (y1-y0));
        double len2 = sqrt((x2-x1) * (x2-x1) + (y2-y1) * (y2-y1));
        double len3 = sqrt((x3-x2) * (x3-x2) + (y3-y2) * (y3-y2));

        double k1 = len1 / (len1 + len2);
        double k2 = len2 / (len2 + len3);

        double xm1 = xc1 + (xc2 - xc1) * k1;
        double ym1 = yc1 + (yc2 - yc1) * k1;
        double xm2 = xc2 + (xc3 - xc2) * k2;
        double ym2 = yc2 + (yc3 - yc2) * k2;

        double smooth_value = 0.5;
        float ctrl1_x = xm1 + (xc2 - xm1) * smooth_value + x1 - xm1;
        float ctrl1_y = ym1 + (yc2 - ym1) * smooth_value + y1 - ym1;
        float ctrl2_x = xm2 + (xc2 - xm2) * smooth_value + x2 - xm2;
        float ctrl2_y = ym2 + (yc2 - ym2) * smooth_value + y2 - ym2;

        CGContextMoveToPoint(cacheContext, point1.x, point1.y);
        CGContextAddCurveToPoint(cacheContext, ctrl1_x, ctrl1_y, ctrl2_x, ctrl2_y, point2.x, point2.y);
        CGContextStrokePath(cacheContext);

        CGRect dirtyPoint1 = CGRectMake(point1.x-10, point1.y-10, 20, 20);
        CGRect dirtyPoint2 = CGRectMake(point2.x-10, point2.y-10, 20, 20);
        [self setNeedsDisplayInRect:CGRectUnion(dirtyPoint1, dirtyPoint2)];
    }
}

Now our app produces nice smooth lines that track relatively well to the intended path that the user naturally drew with their finger.

Adding multi-touch to this app is as simple as handling each individual touch inside the touchesMoved:(NSSet*)touches callback. Advanced drawing apps would likely move most of the drawing code to an OpenGL surface for even faster drawing, but that is beyond the scope of this example.

XCode Files:
Simple Painting with jagged lines
Advanced Painting with smooth lines

In the second part of the series we’ll walk through the same ideas above and see how they would be implemented on an Android device.

Customer journey maps help UX professionals and the clients they serve better understand a particular customer’s needs throughout a series of interactions. Like personas and scenarios, customer journey maps contribute to better user experiences by putting the client in the shoes of the users. You would think that as a Lead Experience Architect, I’d champion these tools, and I do now — but I didn’t always. To be honest, they’re a lot of work — customer journey maps in particular — and I saw too many projects where this work was undervalued and didn’t really seem to contribute to the final product.

My experience with customer journey maps changed when I had the opportunity to work on a large, enterprise project with Boeing. I saw firsthand the value of customer journey maps when it comes to improving communication between stakeholders and the project team, and providing an opportunity for the client to improve the customer experience in ways they might not have thought of otherwise.

I’ve shared more details on this experience in an article for UX Matters, “The Value of Customer Journey Maps: A UX Designer’s Personal Journey.” It just may turn you into a believer, too.

Following Adobe’s announcement that they are ending development of the Flash Player plugin for mobile browsers and shifting their focus, the natural question for developers and businesses with investments in Flash technology is, “What does this mean for us?”

I’m not a business analyst, but here are some of my thoughts as a developer. Adobe’s new strategy, as laid out in their announcement, seems to be:

1. HTML5 for mainstream content everywhere.

2. AIR app packaging for advanced content in mobile environments (where the Flash plugin may be unavailable, but there are low-barrier app deployment channels).

3. Flash Player browser plug-in for advanced content in traditional desktop environments (where app deployment costs are high, but the Flash plugin is widespread).

This distinction between mainstream and advanced content (my own terminology) is subject to interpretation. Obviously, what qualifies as advanced and what’s mainstream will be forever shifting as HTML and browsers evolve. For now, Adobe specifically calls out “advanced gaming” and “premium video” as a continued focus for Flash in the desktop browser, placing those squarely under the advanced content category.

There are obvious answers to “what this means” for some cases. Many consumer-focused websites and web apps — and their developers — that still use Flash for straightforward things should probably begin planning a move toward HTML5, if they haven’t already. On the other hand, web-based games with intense graphics or 3D, or web video services that need special video features, may still want to use Flash, packaged appropriately for browser or mobile app, until HTML advances further. (Exactly what features count as “premium” video and what can be done in  standard HTML5 video is best saved for another discussion).

Source: sharenator.com

But there are other cases where this strategy isn’t as straightforward to apply:

Business process apps in Flex, commonly deployed in an enterprise or non-profit/government environment. Moving to HTML5 could be a big win for these in terms of accessibility and mobile support, but many of them must also function in legacy browsers, due to IT requirements or tight funding. There are options here, like progressive enhancement and script libraries that bridge some compatibility gaps, but they bring more complexity than a straight Flex solution. Adobe seems to agree with this take, having just announced a de-emphasis of Flex in favor of HTML5 for enterprise apps in the long term, while admitting that Flex still has some advantages for the time being.

Desktop-class apps such as publishing and design tools (“web to print”). Arguably, these could fall under advanced content, and the close relationship of Flash Player and AIR (strategy items #2 and #3 above) make it theoretically possible to repackage some of the same codebase for Flash in the desktop browser and AIR on mobile. But differences in interaction paradigms and hardware capabilities between the two are not trivial, requiring careful design, architecture, and testing.

Experiences that mix mainstream and advanced content. There’s no clear and consistent bridge at this point between the Flash and HTML worlds. If you’re in a desktop browser, you can embed Flash content inside your HTML page as always. If you’re in an AIR app on mobile, you might be able to embed an HTML page inside your Flash app (which is the exact opposite capability from the desktop browser case, and has significant limitations. And translating or cross-compiling all that legacy Flash stuff to HTML is not likely to ever be doable in a clean way — Adobe has a limited, experimental FLA to HTML converter, , but it’s will probably never be useful for much beyond simple banner ads. This is a case where a third technology, like a native mobile SDK, may need to come into the mix to smooth the transition.

If you deal with apps that fall into one of these categories, it may not be time to run out and drop Flash, but it might be time to think about branching out, researching and experimenting with alternatives or a hybrid approach. Developers are a key part of this, but it requires customer insight and design, too — which is why I love working at EffectiveUI, where we have cross-disciplinary teams to tackle just these kinds of challenges.

Earlier this week I had the opportunity to speak about the benefits of Git for Android developers at AnDevCon II. My session went well, and hopefully some people have more of an understanding of Git and how it can help them as developers.

As for the event itself, AnDevCon is the best Android tech conference I know of in terms of technical content. The other big Android show, GoogleIO, is  a lot of fun, and you can hear about the newest tech there. However, it’s not all about Android and there isn’t coverage of community projects or lessons from the trenches like you can find at AnDevCon. Not only that, but AnDevCon is able to pull in Google speakers like Chet Haas, Romain Guy and Kirill Grouchnikov.

For me, the highlights from this year’s AnDevCon included two sessions on RoboGuice, a very useful Android DI framework that I can’t work on Android without; two sessions on Android tuning tips from Mark Murphy, the author of several books and tutorials on Android development; and the O’Reilly booth, where there’s always something cool from the Make Magazine guys.

The next AnDevCon will be held sometime at the end of June 2012. Stay tuned to the AnDevCon site for details.

As you may have seen by now, Adobe has announced that they are ceasing future development of their Flash Player plug-in for mobile web browsers, endorsing “HTML5 [as] the best solution for creating and deploying content in the browser across mobile platforms.”

Snickering from the anti-Flash crowd aside, this seems to me like a no-brainer decision, and a minimal loss for mobile. Flash in mobile browsers never performed particularly well, and most of the interesting Flash mobile work is happening with the AIR app-packaging tools anyway, which Adobe says will be the focus for Flash mobile going forward.

However, as my colleague Greg Owen pointed out this morning, this raises interesting questions about the long-term future of the Flash Player browser plug-in generally. This is especially true as tablets begin to blur the line between a “mobile” and “full” computing experience. Microsoft has already echoed Apple in announcing that Windows 8′s new touch-centric personality, Metro, will sport a web browser that doesn’t run plug-ins.

Where does this development leave the traditional Flash and Flex “rich internet application”? Feel free to share your thoughts in the comments below.

As a UX professional, it’s easy to forget what our job is. Or rather, it’s easy to get stuck thinking it’s something less than what it is — something tactical and prescriptive. Some days our job is whiteboarding and wireframing, on others it’s talking to a handful of users, and sometimes it’s doing all of the little things that make design tick — the coordination, the documentation, the persuasion.

Source: duxcamp.tumblr.com

It’s easy to forget that what UX professionals really do is facilitate the conversations that facilitate change. Last weekend I had the opportunity to attend the 1st annual NPR DUXcamp (#DUXcamp) in Washington, DC. An unconference-style event, DUXcamp focused on the intersection of storytelling and design. And it was in this intersection that I was reminded of why we do what we do.

As we met in intimate groups of 20 or so, I saw my UX peers on the corporate (and non-profit) side reaching out and fumbling in a sea of metrics and data, hoping to convince business stakeholders that design decisions were scientifically justified — trying to bring others along on the long leap from observation to inference.

I also saw journalists and business stakeholders from the media industry creating and shaping the future of news delivery. Somewhere deep down there was a knowledge that the walls they had created to protect journalistic excellence from the necessity of ad sales had to be breached, or at least made to breathe. There was no lack of courage behind these efforts, just a need for a little push — someone to help facilitate the conversation over the wall, to make it safe.

Source: duxcamp.tumblr.com

As the day wound down, an overcrowded room of eager attendees took standing room only spots to witness a master storyteller, a facilitator’s facilitator — NPR’s own Robert Krulwich. As he led us down a path from quiet reverence to loud comedic announcement via an array of textures and tempos, he showed us almost without telling, how a story, a constructed conversation, can persuade. “Being a change agent”, he said, “is beautiful and lonely. You must be prepared to be disappointed daily by those looking to maintain the status quo.” I’m hard pressed to recall a better embodiment of our charter.

It’s been a busy autumn for our team as we’ve joined events from one coast to the other. Our first stop was Adobe MAX in Los Angeles, where we learned good things about the Adobe MAX community, and tried to determine where Flash fits in an HTML5 and native app world. We even shared some experiences in a podcast for Nerd Radio.

San Francisco hosted the first ever Android Open conference (see a wrap-up of the event here), where our team learned that Android is more than just a consumer device. On the other side of the country, we attended the Web 2.0 Expo in New York where we shared some design essentials for executives and the EffectiveUI booth was a popular spot.

But we haven’t taken off our traveling shoes yet. On Oct 27-28, we’ll be at Forrester’s Consumer Forum (#FCF11) in Chicago. This year’s timely theme addresses how companies can take advantage of digital platforms and technologies to improve the customer experience. On Friday, October 28, EffectiveUI’s Executive Director of Experience Design, Peyton Lindley, and Suzanne Hamill, Vice President of Interaction Design at Fidelity Investments, will lead a forum to discuss Client/Agency Collaboration: Fidelity Investments’ Lessons From The Field. We’ll be live tweeting the session, as well as several others. We’ll also be in booth 301 to share our experiences one-on-one.

November kicks off with AnDevCon II (#AnDevCon), November 6-9 in San Francisco. On Monday, November 7, EffectiveUI Software Architect Tony Hillerson joins the Android crowd to lead a class on SCM (Source Control Management) for Android Developers Using Git. While SCM may not be the most exciting part of development, it’s essential if you want to avoid lost code and rework. Join Tony as he explains why Git is different, and why different is good when it comes to SCM.

On November 8-9 in Los Angeles, the HTML5 Video Summit (#HTML5Video), co-located with Streaming Media West (#smwest), will address the next generation of online video through sessions, panels, demos and case studies. On Tuesday, November 8, Tony Walt, 3D/Motion Design Team Lead for Effective UI, will take part in an HTML5 Video Content Showcase. Tony will talk about some of the challenges he faced while incorporating HTML5 video as a key component of the new Blue Angels website.

ad:tech (#adtech) hits New York City November 8-10. This event features speakers, panel discussions and workshops to help keep media, marketing and technology professionals on top of their digital game. On Wednesday, November 9, EffectiveUI President Anthony Franco leads a panel discussion: User Experience Matters: Making Sure Digital Experiences Don’t Suck, along with other experts from Microsoft, Experian, POP, and TIAA-CREF.

If you’ll be at one of these events, be sure to introduce yourself to our team. Who knows, you might even walk away with some awesome EffectiveUI schwag!