First off, there doesn’t seem to be THE perfect tool out there for authoring technical books. We came across “all-in-one” applications that were great for non-technical writing, but focused more on the author than the entire process of putting a book together. There are a lot of roles that get involved besides the author(s). There’s technical editors, peer reviewers, production, senior editors, etc. and they all play different roles. Some people don’t even get involved until half way through the process. All that said, here’s some of my notes on various applications we evaluated and/or used while putting our book together.

Communication

When Andy and I first started writing the book I lived in California and he was in Colorado. Every few day we’d discuss the direction of the book or review each others work. To avoid any additional phone charges we’d use some applications for chatting. Some of these might seem obvious, but hey, they work.

Skype
I’m sure a lot of people are familiar with Skype, but I’d say we used it 90% of the time to talk to each other. The quality was awesome and since I was already in front of my computer it made it really easy to jump into a quick call.

iChat
If you’re a Mac user you know iChat. We would use this a lot, but not really for voice chat. We’d use the screen-sharing feature to review material, walk through a sample or collaborate. The quality of the screen-sharing was really smooth and worked great.

Writing

As you can imagine we spent hours upon hours in front of our computers writing. From the get-go we wanted to find an application we could easily work in without getting frustrated over things not formatting correctly. We also need an application that could export to MS Word because that was the format required for reviewing.

Buzzword
What better way to write a book about Flex applications then in an actual application created with Flex. Awesome, we thought. We started writing the book in Buzzword, but gradually discovered it was not to be. There were a couple things that didn’t work for us.

First off, there’s no way to create Text Styles, so we could predefine how text should look for Captions, Headers, Chapter Numbers, etc. We needed that in order to make sure formatting was consistent.

Then there was the horizontal sliding toolbars for paragraph formatting, list styling, images, etc. We dug the toolbars at first, but a lot of what we did revolved around formatting, so we were constantly having to switch between toolbars and wait for them to slide open. Sure, it only takes a second, but those seconds add up.

Sometimes we couldn’t remember which feature was in which toolbar, so sometimes the wrong one would get clicked and then you’d have to click another one. It would have been great if we could have dragged a toolbar out and have it take the form of a palette so we could quickly access the features we needed.

The last thing wasn’t a big issue, but it still came up. To use Buzzword we had to be connected to the internet. This was an issue when I was traveling, specifically while in mid-flight. In those situations I would usually work in another application then copy and paste it into Buzzword when I got a connection.

Eventually we gravitated away from Buzzword, which is a bummer ’cause I liked being able to collaborate on stuff.

Google Docs
We had the same issues with Google Docs as we did with Buzzword. Google Docs does have Text Styling features, but they’re predefined. It also appears Google Docs is integrating with Google Gears to enable you to work off line. This may have helped us, but it’s just barely getting rolled out now.

Both Buzzword and Google Docs were great for the “pre-writing” or smaller parts of the book, like putting together the book outline, bios, proposals, etc.

Pages
Eventually we settled on using Pages. It had everything we needed and was super easy to export to MS Word without any loss of fidelity. Sure there’s no smooth way for collaborating, but we figured our ways around that.

One thing I’m keeping my eye out is for a web version of iWork that ties directly into MobileMe. It would be even better if the desktop version of Pages could sync directly with the web version. Throw in some iChat and you’ve got complete collaboration.

Pre-writing

The stuff I’m calling “pre-writing” are beginnings of chapters, code snippets, thoughts, ideas, links, etc. In our case this type of writing was a collection of thoughts and ideas of what we felt would work in the book, like an evolution of the outline. We’d then take those thoughts and start forming them into chapters. There’s a few apps we found that worked great for this.

Journler
Journler was an application I started using right around the time we started the book writing process. I would use it to capture ideas, images I came across on the web, sample UI scenarios, links, or whatever else caught my eye. I could assign categories and tags to the content and it would automatically list all the resources (images, links, etc.) in another panel, which made it easy for browsing. Best of all, it was freeware and worked with WordPress. Now it looks like you have to pay for it.

Evernote
I didn’t use Evernote at all while writing the book. In fact, I don’t think it was even available then. Evernote was introduced to me by Tony Hillerson while we were working on our 360|Flex preso at the EffectiveUI offices. I just started using it and it seems to have real potential. It’s a desktop application that lets you freely write, capture web pages as text, capture images and more. What’s really cool is it syncs selected Notebooks with the service online, so you can access them on the web as well. Another cool feature is that it will scan photos for text, so you can search for text in photos.

It would be nice if text in photos could be translated to live text for editing. I’m think for handwritten notes, content I took a picture of in a magazine, etc. Being able to highlight areas in text would be nice too. I’d also like to be able to share notes with others, so they can edit them as well.

These applications work great. However, sometimes you can’t beat a pen and a pad of paper. Especially when trying to figure out what illustrations or diagrams should look like.

Distribution

When I say distribution I mean getting files to people so they can be reviewed, edited, etc. There were a lot of people involved in the process and they all needed to have the most current version of every bit of content.

Email
We very rarely used email because it was pretty much inevitable that it would get blocked or get stuck in someone’s junk folder. Plus, using email meant once you got that email you’d have to put it into some kind of organizational structure that may be completely different than someone elses. Probably not a big issue, but we wanted to try to keep things as organized as possible.

FTP
When we first started trading files we used FTP. This quickly became a hassle and had the potential to get real unorganized real quick. Plus, our Pages files would get uploaded as directories instead of files, so we would have to zip them up.

Basecamp
Eventually we settled on Basecamp. It was really easy to keep things organized with the latest version and make sure everyone was notified when the files they were most interested in were updated. Once we started using Basecamp the process became much smoother.

Dropbox
We didn’t use Dropbox while writing the book, but I just started using it and I’m liking it so far. Basically it creates a folder on you computer where you can drop files into and have it sync up with their servers. You can then access those files on the web, share folders with people, add new folders, etc. This is kinda like .Mac, but it’s free (so far). I could see Dropbox fitting into the whole file-sharing thing depending what you were trying t accomplish.

Conclusion

There’s the rundown of the applications that played a role in the process of writing the book. During this process Andy and I kept brainstorming on the “Book Writing Killer App” that would incorporate all the features we needed for ourselves as authors, but also for all the other roles involved. For example, giving technical reviewers certain access rights to do what they needed to, but then also give us the ability to easily address their feedback.

Again, this is my first book authoring experience, so I’d love to hear from others if they had any applicaions they found to be helpful.

After being involved with different types of projects and playing different roles on those projects I have definitely started seeing patterns in the way applications are used to create RIAs and what seems to work best. Different projects have different expectations at the design stages. Sometimes the deliverable is a series of “wireframes”, refined views or a full prototype. For a successful series of applications, these use-cases need to be supported. Based on my experiences I’ve assembled a list of what I’d want in an “RIA Suite”.

Fireworks

For me, Fireworks is my go-to application for UI design. I can rapidly iterate on designs that maintain vector qualities, make rich symbols for quickly laying out views and keep everything pretty well organized. Fireworks CS4 makes it even easier to do the day-to-day tasks with features that seemed to be lacking in CS3. The downside is that I usually have to bring Fireworks artwork into Flash to add animation and maintain vector quality before bringing it into Flex. Filters also have to be removed and reapplied in Flex because they don’t translate the way I’d like. From what I’ve seen, Thermo will help solve some of these issues.

Flash

When creating a UI for a Flex/AIR application it’s usually inevitable I’ll be using Flash. I’ll use it to group assets into a single SWF, package up a font, create a complex UI, or add animations. However, it seems I’m beginning to use Flash less and just doing everything right in Flex Builder. Using Tweener and Degrafa I can achieve the results I’m looking for most of the time, but I can’t give Flash up completely yet.

Thermo

We’ve all heard about Thermo and I think it’s going to address a lot of the issues I have with current workflows. It seems Thermo will be the middle application that bridges the gap between CS applications and Flex. Mockups are transformed into working MXML with the help of a designer-friendly environment. This includes converting graphics to working components, adding animations, creating dummy-data sources, and more. The one thing I have yet to see is how the designer/developer collaboration actually works. What happens when a developer makes a change and how does that get reflected on the designer’s side, and vice-versa?

Flex Builder

Every day that I am working I fire up Flex Builder and start plugging away, so of course it’s gonna make it onto my list. From a design-perspective I use Flex to add transitions, bitmap filters, do layout, etc. I’ll jump into Design View or CSS Design View to make sure everything looks the way I want it instead of compiling the application.

Bridge/Version Cue (RIA Edition)

Okay, this is not a real product, but it’s something I see lacking in the current collaboration between designers and developers. Developers are familiar with version control systems like CVS, SVN and the like, but what about designers? How will designers be able to tap into those same repositories to maintain the fluid collaboration? Use a command line, Flex Builder, FTP? Probably not.

I’m thinking it would be great if a familiar application that designers already use, like Bridge or Version Cue, would make it really easy for designers to interact with a repository. Developer’s might cringe at the idea of a designer having that kind of access, but maybe it isn’t direct. If Thermo allows for designers and developers to directly interact with the same code base I think this would be a nice feature. There’d also need to be a way to cycle back and forth with files and probably need to be able to check them in and out.

Degrafa (Not Adobe)

Degrafa is not Adobe, but every project I work on gets Degrafa added to it. Why? Because bitmaps and static vector artwork can only go so far. I make 80-90% of my skins in Degrafa. This allows me to open up any properties of the graphics to CSS, which means one Degrafa Button skin to create an infinite number of variations versus making separate graphics for each variation. There’s things I can do with Degrafa that I can’t with bitmap or static vector graphics and with the the things planned for Degrafa Beta 3, it’s a no brainer.

So, there’s the rundown. It’s a mix of a little present and future, and I’m sure there’s some tool out there that I just don’t know I want yet I’m looking forward to smoother work flows and tighter collaborations between designers and developers. When that happens there’s more time for innovation.

I’m working in Flex pretty much everyday (I do have to sleep sometimes) and tools play a huge role in the way you operate throughout your day. From a design perspective, I’ve been trying to work in different Adobe applications, like Flash, Illustrator and Fireworks to create application designs from start to finish. This includes every part of the process, from wire frames, icons, “story boards” and all the way through to the final design.

What I’ve found is that none of the applications I work with provide the most optimal solution. There’s things in Fireworks that I want in Flash, things in Flash I want in Illustrator, etc. What ends up happening is I use 2-3 design applications to achieve the final result. I understand that each application has it’s own specialties, and that’s fine, but it really cuts into production time and how quickly you can iterate through application designs. Of course, that’s just the design phase.

After getting the design where I want it, I then have to bring that all into Flex. With the Skin Design Extensions and the Skin Import feature in Flex Builder the process is quickened. However, those solutions only get me 60% of the way there. There are additional skinning nuances that aren’t represented directly in Flex, there are still effects and transitions to be implemented and a slew of other things that I have to do to get the app looking and “acting” the way I want. In my case, I can play both roles to a certain extent, but this process is magnified when there is a hand-off from designer to developer.

Stories like mine aren’t anything new. In fact, I read emails, blogs and threads about these same frustrations. The good thing is that all players in the RIA space are pushing for a solution. We’ve all heard about the problems Adobe Thermo and the prospects of Flex 4 are going to address, but Microsoft is also addressing these same issues.

A while ago, a white-paper called “The New Iteration” landed on my desk. It basically outlines how XAML and Microsoft tools help facilitate a tighter collaboration between designers and developers. A little later, I read a blog post by Ethan Eismann, Design Lead on Thermo, that addresses some of the exact same things. Both use different terminology, but it all points to a common goal. In fact, as I was reading “The New Iteration” I tried swapping XAML out for MXML, Thermo out for Expression Blend, and Flex Builder for Visual Studio, and it still made sense.

At this point, there is still a lot of refinement going on. I don’t think anyone has the perfect solution yet, but the good thing is that we’re moving closer to it. I can’t wait until I can design applications for mobile, desktop and browser in one application and have it “seamlessly” translate into a development environment without loss of fidelity and not having the headaches to deal with when I have to make design changes. Less time needed for implementation of designs means more time to spend innovating, integrating usability testing, and further refining the processes we use. The result is an escalation in the number of ground-breaking user experiences.

I can live with that

Part of that flexibility is allowing users to convert different formats to Degrafa so they don’t have to recreate the wheel. We’ve mentioned we’re working on converting SVG and XAML to Degrafa markup as there are a lot of similarities. However, there are other formats we’re experimenting/focusing on converting to Degrafa, like SWF, TTF, AI, and others.

Based on some preliminary research, I got to thinking, “Wouldn’t it be great if Adobe file formats all had some kind of Common Graphics Language?” A big part of what they do is graphics, right? Granted each application has different requirements and it’d be a whole different scenario to describe bitmaps versus vector graphics, but if there was some sort of common base there would be less of a need to import/export or convert files.

This would almost certainly be a full merger of Adobe and Macromedia formats. With projects like Mars being developed for PDF, MXML-G being used for Flex, MotionXML in Flash, etc. it’s not hard to imagine. This would mean graphics/documents being able to meander across media and device, from print, web, desktop, mobile, etc.

During Deepa’s talk at 360|Flex someone asked about converting/saving Illustrator files to MXML-G and the response was, “Maybe.” What if went further than. What if an Illustrator file used a common language as MXML-G (or was MXML-G?) and you could open it right inside Thermo as if in Illustrator. Or, one feature I’ve seen people use a lot in Photoshop, where you can opt to edit a Smart Object and it opens in Illustrator. You can save that Smart Object and the changes get reflected in the initial Photoshop document.

I know each application serves different purposes and thus each file needs to support the features. However, what if there was a core language and each application just expanded on that core. Then, maybe each application could have the ability to read or not read some of those expanded areas. At the very minimum every application could render the core elements, but depending on the type of application, parts that extend beyond that core would be compatible where it made the most sense. Unless every application could read files from any other application and render them flawlessly

Of course I’m not pretending to know what it would take to implement something like that, nor if it’s even feasible, but my guess is it would take a long time to implement. Part of what spurred all this was realizing some of the disconnects going between different applications and media. It’s doable right now, but it could be smoother. Adobe is already addressing a lot of these things.

With talks of taking Flex mobile and getting ever closer to the Adobe Engagement Platform, there’s are going to be a growing need to bring a lot of the tool sets to a common ground. When we start seeing that happen, traversing across media and device is going to get really easy and very interesting.

I know there may be limited screen real estate on the iPhone, but it just means reworking the UI to make the user experience enjoyable on a smaller device. Of course there’s always room for “Mobile” or “Lite” versions of software, although in some cases it may be overkill to add applications that almost require that larger screen size.

With that said, I couldn’t help but mockup a version of the iPhone home screen with a slew of Adobe apps. Granted some of the apps probably have no business being on the iPhone.

UPDATE: Someone asked about getting the file for these icons. Here’s the Photoshop file.

I “officially” started ScaleNine on December 27th, 2006 with about 3 themes. One theme I had created myself and the other two were from Adobe Consulting. Since that date the annual hit stats were 145,427 visits, 323,763 page views and 90,446 visitors. The number of themes now showcased on ScaleNine is at 17.

Those numbers crazy to me considering ScaleNine is a side-project of mine and I never thought it would go as far as it did. It was really just a response to the number of people who were asking about creating skins on FlexCoders. If you told me a year ago that I’d be speaking at conferences and writing a book based on the knowledge I’ve gained maintaining this site and developing applications in Flex, I would have looked at you as if you were nuts. However, that’s exactly what happened.

I’ve also had the opportunity to meet a lot of awesome people within the industry. Chatting with those people and seeing what others are developing always gets me excited about where things are going and the potential for future opportunities. Meeting new people has offered me the opportunity to work on other side-projects like Degrafa (beta January 1st) and help start the Orange County Flex User Group.

The company I work for is getting ready to launch a really interesting product and I’m excited about the possibilities. I’ve learned so much by being part of the team that has taken it to where it is right now and I look forward to gaining even more knowledge when we go live. It’s definitely an adventure that I’m glad I can play a role in.

The really great thing is that this feels like just the tip of the iceberg. Not only for myself, but for technology in general. With changes in the Flex 4 framework coming and Thermo I know things will be pushed even further. The only prediction I have for 2008 is that it’s going to be an awesome year.

Mike Chambers just released the new AIR logo into the wild. It’s interesting to see the new direction in logos that Adobe is taking. They went from really ornate icons for CS and CS2, to the “element” icons of CS3 to these new abstract shapes with holes in them.

I don’t really mind the new AIR logo. I can see how the 3 circles blobbed together as if in a lava lamp could represent the 3 technologies of AIR coming together as mentioned on Mike’s blog. It also has that triangular arrangement that mimics an “A” for AIR and Adobe or a buzzsaw (Perhaps to cut through the competition?). It is definitely better than cramming 3 letters into a square. I’ll definitely miss the Cursor Rocket of Apollo.

If you want something similar to call your own, you can buy one here for 300 Euro, which is probably less than what Adobe payed to have the new AIR logo created.

I thought I’d check it out, so I signed up and started using it. It’s come in pretty handy and I’ve started using it regularly. One thing I’d like to be able to do is share something with someone and give that person the ability to share it with other people. I tried doing that and it didn’t work. Maybe I missed something.

Anyway, the more I played around with it I started thinking about the other services Adobe is going to be rolling out soon and the services that they already have out there. Of course my mind started to wander and I put together a some directions I could see Adobe Share going. I might be way off, but I think about stuff like this.

Online Version of Bridge
If you’re not familiar with Adobe Bridge, it’s a desktop application that integrates with Adobe’s CS3 products and allows you to manage files on your desktop. Well, Adobe is gradually adding online application offerings, including Photoshop Express, Premiere Express, Kuler and now Buzzword, and I’m thinking more are on the way.

Imagine being in Adobe Share and able to open/edit an image in Photoshop Express which then goes back into Share or on to your desktop. Or maybe open some video clips and merge them together in Premiere Express, or save a video to Share from YouTube. Adobe Share would be an online repository for any media you might want to keep track of and share.

Expandable File Repository
What if there was an option to bring all my Flickr photos, or some of them, into Share to use in other ways. Like bring them into Photoshop Express. Maybe import my YouTube videos in to share to remix in Premier Express. Basically options to bring in files from any other location to be managed in one place.

Then I could create media “groupings” and share that with other people. On a blog it might be something like a slide show, or have a navigator to view different files. You could embed something that would allow you to share, say files regarding a snowboard trip you just took. Images of the mountain, video of you in the halfpipe, an itinerary, maybe an audio clip of you on an ambulance ride after breaking your ankle, could all be shared via one embedded object.

Remote Access
How about the ability to access items in your Adobe Share account from your desktop. Like open an image from your Share account in Photoshop. Maybe even a tab in Bridge called “Share” where you could grab your files. I know one of the reasons for Share is to reduce using bandwidth to share files, so something like this would definitely defeat that purpose.

Maybe I could view shared images and video on my desktop using Adobe Media Player. Then, someone could almost create their own “channel” using Visual Communicator and Premiere. Viewers could watch the videos that person created by accessing that person’s Share account.

Add Some Voice
Another service mentioned at MAX was “Pacifica”, a VoIP solution for Flash. It might be cool to see “Pacifica” integrated some how, maybe in the file viewer portion.

Anyway, it’s really great seeing some of the directions the web is going, not just Adobe. It’s definitely a great time to be involved with all this stuff.

I never really thought about getting credits on a piece of Adobe software, but it’s definitely cool to see (middle, right). Yes, I realize my name is a common one, but I swear it’s me. In case your wondering what I did, you can check out NJ’s post for some insight.

Now that I’m back from Chicago I thought I’d put together a list of features I took away from the “Thermo” demo that was given at MAX. Imagine creating Flex UIs and experience using the very familiar toolsets in Photoshop, Illustrator and Flash. Adobe’s “Thermo” project does that and more with strict emphasis on a tool for a designer to create the front-end of an application. This is the answer to so many questions and issues people have had with the designer/developer workflow. There’s an Abobe Labs page where you can learn a bit more, which includes images.

There were a number of features shown, including the ability to import a Photoshop file and then easily convert artwork into working components. Once the artwork is imported a designer can go through and convert the artwork to working components. When this is done, everything that is selected is converted to MXML with reference to external image assets. One example that was shown was a graphic that was designed to be used as a text input was selected and then from a menu item was converted into a functional TextInput, skins and all. One thing I’m hoping is if you import vector art, the vector properties are maintained and converted to MXML path data and colors, alphas, etc. values remain editable.

For more complex components, like a scrollbar, you work within layers to specify which artwork is which part of the component. For example, you can designate which artwork is a scrollbar thumb by simply dragging the artwork within a layers palette into a folder called “thumb”. I imagine this feature may evolve to support custom components where a developer might specify the different parts of a component, which would translate into folders inside of the Thermo component/skin palette.

Another thing that was shown was the ability to create a relationship between a List and a ScrollBar. So, the List was separate from the ScrollBar, but there was an icon that was dragged to point to the List and a relationship was created. Once those items were linked the ScrollBar now controlled the List.

You can easily work with transitions and effects on different portions of the UI using layers and simplified timelines to do what traditionally may have taken a good understanding of writing those out in MXML. Once you felt your effect was where you’d like it, you could scrub through the timeline back and forth to preview your work.

Additionally, it is really easy to make a dummy data set for mockup purposes. What was traditionally a more elaborate process of creating a dummy XML file and assets has transitioned into a seamless process of using a very visually approach to defining data, editing data and simulating data populating your UI. The data can be worked with via a data grid based structure.

“Thermo” is great because Adobe has focused on patterns and tools a designer is already familiar with from other products and made a really familiar workspace for a designer to create user interfaces for Flex and AIR. The features that were presented were awesome and there’s already people talking about additional features they’d like to see. “Thermo” is an awesome tool, but from what I’ve heard we might have to wait a while, but it’ll be worth it.