blogs | Karl Johnson

Tuesday May 01, 2007

Interested in Silverlight? Join TalkSilverlight!

Maybe you are a Flex or Laszlo developer, or you love Java applets on the desktop delivered through the web, or you are a Microsoft developer who has spent time building .NET clients for the web or the desktop. Or maybe you are an AJAX/DHTML dude. But now you have heard of Microsoft Silverlight - the brand new pre-release platform from the big boys in Redmond. It is still in its early stages, but the concepts behind the platform could prove to be hugely important in the next generation of rich application development. Personally, the opportunity to develop in C# or any other language supported by the CLR and utilize pieces of the .NET framework - all wrapped up in a rich and super interactive package as a RIA - is very exciting. I can't wait to start getting some demos out here. The first step is to grow the community and see what possiblities this platform may provide for.

Regardless of how you feel about Silverlight's chances going up against the very established Flash player and Flex apps that run on it, or how you feel about Microsoft as a company, you know the techy inside of you is excited about what this possibly could mean. And you know you want to play with it! Join the community! There is a new Yahoo! Group out there now to allow designers and developers to collaborate, learn and grow with Silverlight and its related technologies and IDE's. So go sign up and start contributing - questions are the best way to start.

TalkSilverlight is the new group - join at http://tech.groups.yahoo.com/group/talksilverlight/ and get started. For more info about the technologies and where to download the IDE and runtimes, check out http://silverlight.net/GetStarted/.

|<

 

Friday April 06, 2007

Working around Security Sandbox errors in Flex when using BitmapData.draw() (effects and such)

This is not something that you hit every day in Flex development, but when you do hit it, boy does it drive you crazy trying to fix it. Well I am here to save you the time! If you are using BitmapData.draw() somewhere in one of your Flex/Flash effects or distortion utils and you have hit a sandbox security error when trying to play your effect on a component that includes a dynamically loaded image from a remote server, here is your fix!

You can use this on an Image control, a SWFLoader, or a Loader. The key here is to set the loaderContext property of your Image. We need to set the loaderContext property, which is null by default, and set its checkPolicyFile flag to true, so we can tell the Image control (well actually the SWFLoader which it extends) to check a policy file prior to trying to load the image. This tells the Flash Player to chill out on the sandbox error and load the image into the bitmap if a crossdomain.xml file is in place on the image serving server.

Here is what the error probably looks something like:
SecurityError: Error #2122: Security sandbox violation: BitmapData.draw: http://localhost/me.swf cannot access http://stuff/me.png. A policy file is required, but the checkPolicyFile flag was not set when this media was loaded. Ø at flash.display::BitmapData/draw()

There are a couple ways of doing this, but be careful about instantiation and initialization timing when doing it. A straightforward, simple way to do this is to just instantiate your loaderContext object and set the checkPolicyFile flag to true on the initialize event of your Image. This context object must be created AND configured before the Image control attempts to load the image from the remote server!!

Image Tag:

	
       <mx:Image id="myImage" initialize="imageInit()" 
source="http://otherDomain.com/myImage.png" loaderContext="{loaderContext}">

Script Block:

   [Bindable]
   var loaderContext : LoaderContext;


   private function imageInit() : void
   {
      loaderContext = new LoaderContext();
      loaderContext.checkPolicyFile = true;
   }

Now if all goes well, you should be able to generate BitMaps in memory of your dynamically loaded media objects at will - and without this annoying little error. Don't try to just throw a try/catch block around your effect call either. That will do nothing but catch and hide the error and prevent the effect from playing. Hope this helps some!

If you have any comments or questions, drop me a line at karl.johnson (at) cynergysystems.com

|<

Thursday February 22, 2007

RIA's are NOT Websites! Think outside of the browser box...

Everyone thinks of RIA's as web applications that run in the browser. Almost everyone, that is. Some people are able to get their heads out of that so familiar browser box and look at RIA's for what they are - powerful desktop applications that can be run via a browser or from a desktop operating system. While Macromedia was out in front in producing RIA technologies, and coining the term Rich Internet Application, I am afraid that term is rather misleading. And several people have asked the question "Is a RIA a RIA if it is run on the desktop? What about Apollo?". Perhaps "Rich Applications" or "Rich Experience Applications" will replace the RIA acronym as we move forward in the world of blending the browser and desktop experiences.

You see, RIA's are NOT websites. They can do an excellent job as acting as a rich and very usable and functional application that a user can use via the web without having to install anything from the developer, but they are not content focused websites. They are applications! Every time Adobe comes around asking for feedback from the development community about what they want to see in Flex, so many developers immediately respond with suggestions like deep linking and SEO optimization. These things are of course important to anything running on the web that you want people to be able to find and access like content, but why think this way when approaching a RIA? If you absolutely need to deliver a rich experience and still meet the traditional web site requirements around content, it very well can be done with Flex, so do not fret. But if those things are in your RIA's requirements, just take a step back to make sure you are approaching your next great app from the right perspective.

Up above, I talked about the few that have been able to climb out of the browser box. One of those people is Ryan Stewart, who maintains a personal blog on RIA's as well as a ZDNet blog.

I highly recommend you check out his post here. I have been trying to figure out a way to wrap up my thoughts on this exact point for a while, so once I read Ryan's great post it inspired me to write a follow on. Thanks for the great read Ryan and the vision to see beyond applications as websites!

Comments, love letters, anti-rants: karl.johnson [at] cynergysystems.com

Karl

|<

Wednesday February 14, 2007

RIA Usability is KEY Part 2 : Less is More!

In this second part of my impromptu "series" on RIA usability, I want to cover simplicity in design as far as it applies to the usability of a rich internet application. "Less is More" is an often used phrase in the English language, but seldom used to refer to functionality and interactivity in software. Quite the opposite usually. And just because your application is rich in design and capabilities does not mean it has to be overflowing when it comes to things a user can see or do at any one time. I am not a visual designer and I don't claim to be one. We have an awesome group of RIA visual designers here at Cynergy in our User Experience Group, so the rest of us don't need to focus on making the pretty picture designs. But everyone involved in RIA development needs to focus on the usability of the application, and the way any given screen or component is put together should take the "Less is More" saying to heart.

"Count the buttons!" exclaims Over-C CEO Michael Elliott as he demos the Cynergy developed enterprise RIA Over-C.net to a potential client. He pretty much uses this phrase every time he demonstrates the software. He loves the fact that there are very few things a user can do at any given time - or more importantly - he loves the fact that his customers will love it.

You may be thinking that limiting what a user can do is bad, and I would have to respectfully disagree. Of course you want your app to be that killer app that does more than any of your competitors, but if a user does not know what to do and when, then your app really does very little. Maybe it does a lot for you, but very little for the user, and the user is who software is built for. (Shocker, I know!) When a user only has a handful of buttons or clickable images or controls to interact with at one time, they suddenly have this feeling of knowing how to use your application. Even if they have had no costly training or have logged few hours experimenting with your interface to become familiar with it, they know what to do. This is a big win win and accomplishes a pretty huge goal in any software - being intuitive for your users. It is key to establish an implied flow for the users behavior that feels natural to them by simplifying your design and your user's potential actions.

Designing this flow is a combination of long ago established software UI paradigms with actions that just feel right and make sense. Don't get me wrong, this is a very fine line to walk and must be done with care. Especially when tackling a problem that we so often face at Cynergy - developing a great looking and unique business application that is targeted at users who have spent years doing things the way the other guy's application did it. Breaking the mold can be very hard and is not always the best way to go, that is for sure. Walking that thin line means coming up with a user flow that feels familiar to them, but at the same time, improves their efficiency and accuracy of accomplishing their tasks. As well as making it more fun for them!

There are two phrases or sayings that you may hear when talking about software usability and design. "Keep It Simple Stupid", or KISS, and "Design it so your grandma' can use it.' (or something similar). These both provide pretty good rules to live by, but software development is never a one size fits all design process. While designing for a clean and simple user flow, remembering your target user is paramount. If your target users are developers or power users...then it really does not make much sense to dumb down your app to the point where your grandmother could use it. My grandmother is 93 and would never even dare try to turn a PC on. No point in making this app easy for her - but it should be easy and intuitive for your target users. Maybe it does not need one giant flashing button to indicate to the user how to save the form, but a few appropriate placed buttons or icons will solve the problem while not presenting more options to the user than they really need at any given point in the app, or at any given view at a time.

Feel free to check out demo videos of four of the many RIA's we have developed at http://www.cynergysystems.tv. Including the app that hosts Cynergy TV, which is also a RIA we did.

If you are sitting there thinking that it is ridiculous to expect a RIA developer to not only be an awesome, innovative coder but also be able to whip out simple, yet highly effective user flows and design - you are NOT alone! And it is rather ridiculous. RIA's are complex applications on a lot of dimensions, and it takes a team of talented people with different skillsets to create a really successful RIA. Our VP Dave Wolf put this very well in his post a few months back, "It Takes a Village." Check it out.



Comments, questions, feedback, anti-rants - karl.johnson[a t]cynergysystems.com



|<

Friday January 26, 2007

RIA Usability is KEY : Part 1 : Always Provide User Feedback

Usability is key when it comes to building a great RIA. Super key! No matter how functional or pretty your app is, never forget about usability...never forget about the little guy! If you do, your app will fail. Even if every executive thinks it is the next best thing, if your user's can not use it intuitively, then they simply will not use it at all.

Developers: RIA != Website

One of the first rules of a good user experience is to always provide user feedback - don't leave your users in the dark and don't leave them hangin' while your app has to do something really tough. Tough things like loading a complex piece of the app, or loading a large (in file size) image. These are "tough" not because it is hard to code or hard for the Flash Player to do obviously, but because no matter how well you code your app, loading large files at runtime can take an indeterminable amount of time.

So let's make sure to handle this case right and always provide user feedback. Users quickly and naturally think the app has hung or crashed if they don't feel like they know what is going on. It is amazing how a user's feeling about an app can immediately change from negative to positive just because they see a little loading animation while they are waiting for the pieces to finish loading. Poor performance is no longer the first thing that comes to mind when your app is mentioned.

Preloader and loader graphics and animations are huge in Flex, and a fabulous way to provide a good user experience while your app is loading a large file, or especially when your app is loading its self. For the sake of showing just how easy it is to improve the usability and perceived performance of your RIA, let's do a quick and incredibly easy example of exactly what I am talking about:

Traditional web app: Launch

Your new RIA: Launch

Now this is obviously a very subtle enhancement, and my example is obviously a very watered down version of a RIA (to say the least), but using a technique like this wherever you are loading images or large pieces is a great idea, and there are a ton of ways to accomplish this. If you want to be able to present an image or component that changes based on how much of the image has been loaded so far, you will want to listen on the progress and complete events of your image and update the loader's graphical display to indicate the state of the load operation. You can use your own preloader swf, a ProgressBar component, or something else. This is probably the best user experience, since the user feels like they know when the operation will be complete. Of course, progress bars have had pitfalls since the beginning of software time, but for images and things like that, they work great for the most part.

You may have noticed that my example SWF does not indicate how much has loaded - that is because I implemented an indeterminate loading indicator. A lot of software today, including most of Microsoft's new installers, use these because they have decided that determinate progress graphics can be...well...worthless. That is not why I decided to go that route for this example though, I did it because I wanted to show you the absolutely easiest way to provide user feedback when it comes to doing something like loading an image. And here is how I did it (feel free to count the lines of code!):

Super Quick Loader Image:

	
<mx:Image id="loadingIcon" source="@Embed('loading.gif')" horizontalCenter="0" verticalCenter="0" 
   visible="{sceneImage.percentLoaded != 100}" />
<mx:Label text="Loading..." verticalCenter="18" horizontalCenter="0" color="#ffffff" fontSize="10" 
   visible="{sceneImage.percentLoaded != 100}" />

Entire App Code:

<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" backgroundColor="#000000" >
	<mx:Button label="View Image" horizontalCenter="0" top="5" click="imageCanvas.visible = true;sceneImage.load()" />
	<mx:Canvas id="imageCanvas" verticalScrollPolicy="off" horizontalScrollPolicy="off" backgroundColor="#000000" top="40" height="100%" width="100%" visible="false">
		<mx:Image id="sceneImage" autoLoad="false" source="http://www.cynergysystems.com/blogs/blogs/karl.johnson/Usability/car_small_1.jpg" verticalCenter="0" horizontalCenter="0" /> 
		<mx:Image id="loadingIcon" source="@Embed('loading.gif')" horizontalCenter="0" verticalCenter="0" visible="{sceneImage.percentLoaded != 100}" />
		<mx:Label text="Loading..." verticalCenter="18" horizontalCenter="0" color="#ffffff" fontSize="10" visible="{sceneImage.percentLoaded != 100}" />
	</mx:Canvas>
</mx:Application>

Notice I didn't have to implement a loader component, or listen on any events - I only had to bind my loading image and label to the percentLoaded property on the image component. We are binding to make sure that property does not equal 100, or 100% loaded. Inline binding like this is awesome in Flex, and makes life so much easier. Depending on your parent container, you will want to make sure to bind your visible AND includeInLayout properties to percentLoaded, or you may run into your loader image hiding but still taking up space. That won't however negatively affect it in a canvas container like this.

That really has to be the absolutely easiest way to quickly throw in a usability enhancement like this, so now you have no excuse to pass over a little detail that can have a big impact on a user's over experience with your RIA!

Maybe you found this useful, or maybe not. But the key takeaway should be that always involving the user and letting them know what is going on at all times is a big key to great usability in great software - and is also Part 1 of my RIA usability blog series!

Any comments, question or feedback, email me at karl.johnson [at] cynergysystems.com

|<

Thursday December 14, 2006

Integrating Yahoo! Maps into your Flex 2 Application without using the Flash IDE

Map It!

Yahoo! Maps is built in Flex and is wrapped in a SWC so developers can very easily integrate slick mapping into their Flex apps by just dropping in a component. Very cool! Oh wait...that is Flex 1.5 it is built in! It natively integrates perfectly if you are building a 1.5 app, but chances are that these days you are using Flex 2.0 as your platform or choice.

When I decided a few days ago to try and integrate Yahoo! Maps into one of my Flex 2 apps, I did some searching to find out the best way to do it. I even asked around on the Yahoo! dev mailing lists. Just about what everyone says is "Open the Flash 8 IDE, create a new fla movie, and import the flash component from Yahoo!. Then add the functions in the AS scripting window that will interact with the map....". And I am sure that solution works fine. But for most Flex developers, creating flash movies to do pieces of functionality for our Flex apps is just not the way we roll. Maybe it is just me, but I really wanted to do this purely in Flex.

So here we go - not an earth shattering solution, just a detailed example of how to integrate Yahoo! Maps with flex on flex, without fla's or iFrames.

LAUNCH THE EXAMPLE

What is Required?

Yahoo! Maps SWC

Yahoo! Maps Application ID

Flex 1.5 Compiler

Flex 2.0 Compiler

1. Download the Yahoo! Maps SWC

Here

2. Get a free App ID from Yahoo!

Here

3. Create a new Flex 1.5 SWF with the Maps component

This is a very simple Flex 1.5 app. To get the basics working, you just need to compile one mxml file into a swf. In my case, I called the swf maps.swf. Since the purpose of this blog is not really to teach Yahoo! Maps, I will refer you to their really good starter guide here. But if you want to take a look at what I implemented, check out my source code here.

3. Establishing the receiving LocalConnection

We have to use a LocalConnection to allow the Flex 2 and 1.5 apps to talk. It does not work quite as natively as you may think because both AVM‘s are in play in this situation.

In you mxml file for your 1.5 app, create a variable of type LocalConnection, and then call the LocalConnection constructor for your class instance on initialize of the application. Also on init, you are going to create a function that is accessible via the LocalConnection so your Flex 2 app can talk to the map. In this function, you will perform any API calls that are needed, and can also accept parameters form your Flex 2 application (which in my example I take an address from Flex 2 and add it as a pushpin on the map). I call this function showListing(address). Take a look at my mxml source for this here. Don't forget to call "connect('connectionName')" on your LocalConnection as well, and make sure that the name of the LC you provide as a string is the exact name that you use on the sending LocalConnection end - which will be in the Flex 2 app.

4. Create a new Flex 2 Project

Using FlexBuilder or whatever your way of choice is, go ahead and create or open the Flex 2 project/mxml file that is your main Flex application. Make sure that you have compiled your 1.5 app into a swf so we can easily load it into our main app. Create a SWFLoader component instance and set the source to be the 1.5 SWF you compiled. Embedded always makes for a better end user experience in my opinion (source=“@Embed(‘maps.swf‘)”). My Flex 2 source is here.

5. Establishing the sending LocalConnection

Same steps to start off here, just create the LocalConnection instance and call the LocalConnection constructor on initialize of your application (or whenever you want to start using the maps). In my example, we don‘t need to have the two swf‘s actually talk unless you want to allow a user using you Flex 2 app add something to the Yahoo! Map. So on click of the button, we call “send()” on our LocalConnection and pass it the name of the LC, which again is the same as the name used in the 1.5 app. Your connection is registered in the FlashPlayer under this name – and if they are not the same on the sending and receiving end, they will not be able to talk to each other. In addition to the LC name, we are going to pass send() the name of the function we want to interact with, as well as the paramater(s) we want to supply that method with. In this case, we are going to call the showListing function which we defined on the receiving LocalConnection. One param for us, the address that we want to have added as a pushpin, which we will get out of the flex 2 text input. My Flex 2 source is here.

Done!

So, I know I didn‘t paste in all of the pretty formatted code examples to show exact step by step, but hopefully the linked code examples will show you everything you need to know!

Wednesday December 13, 2006

Joining the blog ranks at Cynergy

It's blog time!

Allow me to introduce myself. My name is Karl Johnson and I am a RIA developer, specializing in Adobe Flex development, with Cynergy Systems in Washington, DC. I am new to posting on the Cynergy blogs, but have been working directly with Flex 1.5 and 2.0 for over a year now with Cynergy. You may have seen me around on flexcoders or met me at one of the tradeshows we have sponsored this year. If not, I hope to!

It has been a crazy, fun year in the RIA world. Flex adoption has exploded! Cynergy has been steadily growing and we have an amazing team of talented RIA developers, as well as diverse backend developers (.NET, Java, CF, etc), that allow us to put together killer rich internet applications for our clients - front to back. Not that my blog is meant to be an advertising campaign, but after representing Cynergy at Flex Seminar in NYC and AJAXWorld/RIA Conference in San Jose, CA, I feel like I need to quickly speak to something that several people seem to have a misconception about. You see...Cynergy has been a major player in the Flex arena, and we take great pride in supporting the development community via Flexcoders and trying to help build the Flex market as much as possible. We have delivered some sweet looking (and acting), rich apps for HUGE clients. All of these great things have lead to the community thinking that we are a UI development company. Now that is not necessarily a bad thing to be - but Cynergy also takes pride in putting together systems from front to back, or soup to nuts if you will. Killer apps not only have killer front-ends, but must also have killer, efficient and smart backends. That is where I personally feel like we really excel; putting it all together.

But anyway, I now feel like this has been too much of a marketing blog and I want to get away from that - this blog is meant to be informative and helpful to those in the RIA community. My first post (sometime soon) will be on integrating Yahoo! Maps Flex components into a Flex 2.0 app. This is much trickier than you may think, because Yahoo!'s components are Flex 1.5 only. I have done this a way I think you will find a bit easier for the average Flex guy and I want to share it with the community.

But until then...keep coding and making the internet a better place to be, one rich app at a time!

|<

Karl