So, as most of you know, I'm not an Apple fanboi or an iSheep. Heck, I just got my first iPod a few weeks ago, a Shuffle. I got it free, otherwise I would never have purchased it. Truth be told, it's actually a pretty sweet device and very well built. But not nice enough for me to fork out a couple hundred bucks for.

So, when I discovered Apple was releasing Safari to PC my response was pretty much "oh great, another browser on the PC". My first 3 months experience with Safari was less than pleasing, it would crash and never launched. However, recently Apple released an update and I've not had the problem since. Overall, its a good browser, fast, and doesn't require me to do any CSS tweaking to get things to display on my sites the way I want them. But I do hate that bushed aluminum look that's so prevelant with Apple's apps. I guess it's like one of the main reasons I am still using FF as my primary browser.

Anyway, I have recently started using Safari more and more. For what? Well, it is now my Flex application testing platform of choice. Why?

1. it doesnt interfere with my Firefox sessions
2. It doesnt cache as bad as IE
3. ServiceCapture works out of the box with Safari

So, if you are doing Flex development on a PC and are sick of your testing crashing your Firefox sessions, or hate the way IE constantly caches your SWF, give Safari a try.

One of the coolest features of Flex 3 is the RSL functionality. When you utilize this option it caches the framework to a swf file. If the user has already visited a site which has a Flex app that is built using the same framework version as you they do not need to download the framework as part of your movie. This means much faster load times and overall, much smaller swf files. It's pretty nifty.

Except there are some catches! A project we are working on is for data driven widgets throughout a website. These should be small in size, no more than 70-80k. We'd reached that goal for the UI functionality at 72k for the most complex swf. That is, until we added in the imports to pull data in from a simple web service. All we do is pull in some small XML packets and parse the data out, a pretty menial task. However, after we imported the soap Webservice (import mx.rpc.soap.WebService) we noticed out file sizes increased by 100k!

Now, one would think this would be cached with the RSLs, but apparently not. Mike Huntington pointed out in the comments that the LiveDocs contains information on the RSL for RPC. After I reviewed the documentation again I found out this is indeed true. Thanks Mike! So, after a bit more research on how to implement this, I came across the Adobe Wiki with instructions on exactly how this is done. I added the RPC RSLS, recompiled the app and was down to a manageable 77k. Nice!

That being said, you may want to monitor your export builds frequently through your development cycle to see what's increasing your SWF sizes and determine if there's a way around it. For backend systems this won't cause much of a ruckus, but if you have Flash apps (or, more appropriately, widgets) for public consumption a 200k swf could be cause for concern.

NorCalFlex will have a Flex 3 and AIR launch party on February 28th. If you live in the area be sure to come and check out our special presentations, possibly win some cool prizes, record your own 30OnAir video and have some good clean RIA Fun! Check out NorCalFlex.com for details

This is just a reminder that Ryan Stewart will be speaking with us in Sacramento on January 23rd. I've just received a large box of swag (including an iPod nano!), so there will be a lot of give-aways!

Event Link: http://www.norcalflex.com

See full details

Everyone seems to have an opinion on Adobe.com, most of it is pretty negative. Many of the folks I see bagging on the site the most really have no design skills or experience. Frankly, I am no designer, nor do I claim to be. However, I have led a number of projects and guided the design and won awards for these sites. I'd like to think I know good design and UI and I think my clients tend to agree for the most part. However, I've been told that people who have a positive view on the Adobe redesign are only saying this because "they want to make others look stupid". Quite the contrary. I think I would prefer to hear from folks the positive things about the redesign in addition to the negative things. I've waited a while to express my views so that 1. I could really examine the site and how I felt about it and 2. Because I didn't want to express myself based on my irritation with folks who can't give a fair analysis.

My initial impression of Adobe.com is mixed. I really like the navigation and how easy Adobe has made it to find the information I need. One of my biggest complaints with Adobe prior to the new release was how much time I had to spend on their site to find the information I was seeking. Adobe has succeeded in cutting this time in half. To me that makes the redesign worth it. I do not think many folks consider this when firing off their criticism.

I also really like the new color scheme. The contrast adds to the readability and the site no longer reminds me of a newspaper. The typography is excellent. Compared to the old site its much (!!!) easier to read. For someone like me who spends 1-2 hours a day gleaning information from Adobe's resources I find this very important.

Now onto the bad stuff.

The Flash animation on the homepage is humongous. I do not know what is up with that, but I would be happy to see it 30% smaller at least. It consumes too much real estate, especially for folks who do not run high resolutions like tech folks do. I often send clients to Adobe.com to research the technologies we use in their solutions. It's not a great impression when a Flash movie overtakes the page.

The backgrounds have to go. A simple gray gradient like the homepage has is nice and elegant without drawing the eye away from the content area.

The content areas need to be widened and centered. The left alignment is not good in high resolutions. Also, I think designing content for 800x600 is a disservice to the web. 800x600 is an archaic (IMHO) resolution which needs to be forcefully pushed off the web. Sure, there's a lot of people still running 800x600 because they claim that in 1024x768 or larger the text is too small for them, but this is because they haven't really been configured correctly. A screen with a higher resolution is actually far easier on the eyes.

The search box needs a submit button. Seriously! I was on a browser last night that didn't have much functionality and no keyboard, it was a touchscreen. I couldn't tell you what browser as it was a proprietary system, attached to a stationary cycle at the gym. However, there was no ENTER button and I was unable to search the Adobe site. This could prove to be an issue with kiosk systems.

Lastly, the site degraded miserably on the above browser. The navigation failed to work properly (which is why its critical to have search that works in deprecated browsers) and many of the content areas were not at all displayed. Im wondering how well it degrades on other older browsers. While I am a proponent of keeping up with technology, some of these older kiosk systems are still in operation in airports and other public places. Although side-scrolling and lack of plug-ins such as Flash will make browsing tougher it is critical that content always be displayed in these older browsers and readers! It's OK to make a site that doesn't work perfectly in deprecated browsers, but always, always always make the content available.

While it seems like I have a lot of criticisms about the site I think most of what I am criticizing can be easily fixed with not a whole ton of effort. Overall I think Adobe is on the right track with the new design

I have been building Flex apps for well over a year now. One of the main struggles I come across is really how to do certain things with the interface. Sure, I have a stack of documentation (online of course) which defines the properties, events, tags, etc to me, but nothing that really tells me how to put it all together. Until now!

Adobe has released the draft of their Flex Interface Guide (FIG). So far, it looks like it's just what the doc ordered.  It also looks like Rob Adams is responsible for most of the content, which is great because Rob is part of the User Interface Group at Adobe.

I think of particular interested to me will be the sections which are not yet finished:

• Part 6: Guiding with motion (Coming soon!)
• Part 7: Making your application fast (Coming soon!)
• Part 8: Making your application safe (Coming soon!)

These are the areas where I am problably the weakest, so I definitely look forward to those. When I am done reading the guide I'll give a quick review.

Another great Adobe event, I'm sure! The camp will cover topics including Flex, AIR, AJAX and Flash. PayPal and Yahoo will also present. The event is in SF, CA on Nov 5, so sign up now!

http://www.eventsadobe.com/devcamp

Scott Stroz let me know this morning about his new Flex Blog Aggregator. You can access it via www.flexbloggers.com or www.allyourflexarebelongtous.com.

It's built using the http://www.coldfusionbloggers.org/ engine it looks like, so it should perform as smoothly as ColdFusion Bloggers.

Thanks Scott!

Got UI design skills? Adobe (thanks guys!) has been kind enough to donate a copy of ColdFusion 8 Standard as the prize for the person who comes up with the best interface for Kalendar.

There are a few requirements so please read them carefully:

1. All entries must be received before October 13, 2007 12:00AM. Entries submitted on or after this date will not be eligible.
2. Designs must be delivered in a PSD files, with all layers intact so it can be dissected
3. You must provide design for the following
   • Each Kalendar view, as show on the demo site (day, week, week as list, month, month condensed). There are 5 views, so please verify you have designed these views.
     
   • The admin screens, which can be accessed on the demo site via the "admin link. There are 3 screens (add/edit form, category manager, file import)
4. You must provide a design guideline which outlines the colors and fonts utilized
5. All buttons and form elements must be designed
6. The tooltips, which appear when your mouse hovers over an event must also be design
7. You must send your files as a ZIP archive.
8. Email your entires to kalendardesign at g mail dotcom
9. You acknowledge that your entry becomes property of the Kalendar project and will be licensed under the Apache 2.0 license.

It is not necessary to provide XHTML or CSS templates. However, if you would like to provide these we would be very appreciative. If you do provide these the XHTML and CSS must be able to be validated.

It is also not necessary to provide a skin design for the Rich Text Editor in the admin (the description field), however you may do so if you like.

A Winner will be chosen on Monday, October 15th. Winners will be notified via email. All entries will be posted publicly for all to view and the designers will be given credit for their work. The winner and winning entry will also appear on this blog.