I’ve just about had it with WordPress and I’m moving my blog to blogger. WordPress’s UI is terrible, their feature set under-developed (I have to pay $10 a year for my own CSS?!) and their restrictions on importing SWF’s from external sites simply ridiculous.
The new blog will be found at http://www.RJRIA.blogspot.com. Go check it out – there might be something great up there even now.
The new blog is going to be more general. While I guess I never stuck to Flex specifically in the <10 posts I have here, the new blog is going to be titled to make it easier for me to talk about RIA development in general, design philosophy, and experience design as well as Flex.
If you have any good ideas about the title, I’d love to hear them!
In Flex, there’s unfortunately no easy way to make this layout work:
<form item’s label>
<form item control>
So if you, like me, have a layout that requires a prompt (something like “your email”) to sit directly above a form item (say a text input), you’re going to have some trouble.
You might say, well, why not just give the form item no label, or an empty label, and put a “Label” control on top of it, like this:
<Label text=”your email”>
Great idea! Unfortunately, this won’t give the layout you desire because Flex still allocates some space to the form item’s empty label. Your “Label” control will be somewhere around 3 pixels to the left of your TextInput. Awesome.
Does anyone have a good elegant solution for this that doesn’t involve any of the following?:
a.) re-writing FormItem
b.) using an absolute layout
c.) shifting the Label control to the right
I’ll update this post if I find one, but in my frustrated fury I wanted to get the question out there. It seems like this sort of thing happens to me a lot with Flex….if you’re not working very soundly within the Adobe prescribed box for how their components should be used, you’re going to be jumping through hoops. It’s stuff like this that consistently make me worried about estimating how long it’s going to take to complete any part of a project – if things work in the way they seem they should, it shouldn’t take long, but who knows what weird restrictions Adobe has on the object I want to use?
If you haven’t checked it out yet, zip on over to Picnik and enjoy one of the best Flex RIA’s I’ve seen. Here’s why:
- It solves a real problem. People need and will use a good picture editing application. You shouldn’t have to use a sledge hammer like Photoshop to remove red-eye or increase the contrast in a picture, and the millions of small photo editing programs that ship with cameras just don’t cut it.
- It has a great interface. The people at Picnik payed a lot of attention to usability, and it shows. The interface is clean and simple enough that I can find everything I need but not so simple that something I need isn’t there. It’s focused on letting you perform basic editing to pictures, and it does it very very well.
- It’s better in Flex. One criticism I hear frequently of Flex/Flash is that there isn’t a need for it. Picnik is a good example of an application that would’ve been at least 20 times harder to develop in Ajax and wouldn’t work as well as it does. There’s a good reason to use Flex for an application like this (Flex has excellent built in bitmap editing features) and they use it wisely. The transition animations are simple and enhance the user experience rather than taking up too much processor and distracting from it.
- It’s better as an internet application. I can use Picnik from anywhere and it works fine. I don’t need an application this light-weight installed on my computer, clogging my registry, taking up disk space, probably running in the system tray.
- It uses social networking intelligently. Rather than trying to re-invent facebook or flickr or myspace, picnik ties into these services more or less seamlessly and increases both their value and its own.
Overall I give this application two thumbs up – this is a real 10. Nice work, Picnikers.
Social networking is the latest and greatest fad on the internet today. Facebook and MySpace continue to post ridiculously high page counts – in the billions per day – and somehow manage to keep nearly all of their users checking back at least once a week, many of them several times a day. It’s the perfect market for advertising, probably the largest source of revenue available in web 2.0, and the best way to keep people hooked on your site.
All of this popularity has lead to a slew of social networking applications. Revisionist approaches to blogging, whether it be twitter or tumblr, are trying to make it easier for people to tell each other what they’re doing. Web 2.0 IM clients – complete with mispelled names, beta users, invitations, and ground reflections – offer slight benefits over traditional instant messenging and it seems like nearly every RIA I’ve worked on during the last year has incorporated some sort of “share this <whatever> with your friends!” feature.
Some of this is good. I read a great review of Twitter lately, and while I’m still hesitant to believe it’s more valuable than setting an away message, I might believe it’s valuable. But at the same time, a lot of this is bad, and we’re losing site of some important application development values in pursuit of the latest trend.
I think there are two principles of good application development being lost in all this social networking buzz. The first is to avoid remaking the wheel – don’t expect users to accept an application that doesn’t do a significantly better job than the one they’re already using. Pownce invitations have been flitting around our office like the flu this week. By next week, we’ll have all gone back to using our combined instant messenger clients (whether Adium or Trillian), because all of our friends and clients are on Yahoo and AIM, and Pownce’s file sharing feature isn’t enough to keep us interested.
The second is not to clutter your application with features users aren’t going to use. Your application might be cool and really useful, but if it doesn’t specifically relate to groups of people and the way they interact, asking us to participate in an online community focused around your application seems silly. Imagine if Google Maps had a “share this map!” feature, and it required us to create a login and password and then spam 9 of our friends with the map we’d just found. No one would use it, and that’s why it’s not there. Google maps does a great job of providing users with maps and directions, and that’s all it needs to do. Users know how to cut and paste a URL to send email to their friends – we don’t need a “share this <whatever>” button.
Last year I worked on an online book reader application as part of a team contracted to Random House. During part of the design phase, someone suggested adding features to allow users to comment on the books they’d read. The comments would show up inside of the book highlighting sections of individual pages people had commented on. Users could come back often to see what other people had said about the book and see comments on their favorite pages. At the same time, we developed the application in such a way as to make it easy for users to embed a version of it on their own web-page. If you were interested in a book, you could paste two lines of HTML into your myspace page and have the application installed. The commenting feature didn’t make sense – no one wants to flip through a book to find the comments and users simply weren’t going to check back frequently enough to read them. Since it was so easy to embed the application on a blog or myspace page, users were much more likely to post their comments on the blog – the application that already addressed a user’s “commenting” needs. The commenting features were eventually dropped and the application we developed was very focused and very successful.
I feel like I’ve seen this story repeated on just about every application I’ve worked on since then with varying results – we have an application that does X, but since social networking is “hot” someone tries to twist the entire thing to have a social networking angle. I can quite literally divide the applications that succeeded in gaining user acceptance from those that didn’t along the “unnecessary social networking” line – those that succumbed have almost all failed.
There are of course times when social networking DOES make sense. A great example is the Discovery Cancer Collage which my company recently worked on. The application allows users to upload images and videos and text about their struggle with cancer, similar to the way the AIDs quilt works in the analog world. The application has a real need for social features and meets a need that more ‘traditional’ social networking applications can’t. It uses social features to provide real value, and doesn’t force social networking as some awkward side feature.
The bottom line is that Facebook and MySpace have 98% of a user’s social networking needs taken care of. If you aren’t providing something that falls in that remaining 2%, social networking shouldn’t be part of your application. Don’t let your application’s focus stray just because of the latest internet fad, or your user acceptance will certainly suffer.
Lately I’ve been seeing these errors in Flex Builder and not been able to find any good reason why they’re happening. It seems like the errors alternate – sometimes it’s one, sometimes it’s several of the other – and there’s no easy way to figure out why they’re happening. Usually they’ll go away if you clean the project enough, but that’s a huge waste of time, so I’ve spent a few hours scouring my code and removing anything that might be causing the errors.
I’ve found that these errors can be caused by several different conditions. FlexBuilder doesn’t handle them well (indeed it seems to have exceptions in either it’s own environment or the compiler), so you get this generic error message instead of something useful.
Here’s a list of problems that I’ve found that can cause these errors. Hit up the comments if you have any others:
1. Forgetting the semi-colon at the end of your member variables.
Michael Imhoff documented this one first. For some reason, flex builder doesn’t flag this as an error while coding, and it doesn’t throw exceptions in the build if you manage to make it compile.
2. Having the same namespace listed twice with different extensions in your mxml
should be this:
or with the default namespace declared, obviously – as long as there’s only one namespace linked to com.site.stuff.core.*.
3. Having the same import declared twice in an AS file or embedded AS in an mxml file
4. Commenting out certain lines of code and rendering trace statements unreachable.
I’ve never seen this, but it was documented as one way to get the error on Flex Coders.
According to Matt Chotin in response to the FlexCoders listing, this is a documented issue. Hopefully it will be fixed in Flex 3.
Until then, good luck!
I received an invite to Joost last week and was finally able to check it out. In a nutshell, it’s one of the best applications I’ve seen in a long time. The content is nice – it’s fun to watch TV on my computer – but what I love even more about Joost is the usability.
Here’s a list of the top 5 thing you can learn about rich applications from Joost:
1.) It’s focused. Joost is an application that brings TV to your desktop in a way that works. It has some other features, like show recommendation and chat, but they’re relegated strictly to the background. The focus is on TV, and you know that from the second you start up the app. Too many apps springing up these days are trying to leverage some neat trend first and promotetheir product/service second (“social networking” is driving me crazy.)
2.) It just works. The developers have obviously taken some pains to make sure that Joost just works for me, and I love that. I don’t have to worry about configuring a bunch of settings or setting my bandwidth or selecting my player or authorizing my plug-ins. The controls are simple and make sense, and if you close Joost in the middle of a show, it opens back up later to the place you left off. In a world full of applications that only really work after an hour, or even ten minutes, of re-configuring your computer, applications that work so smoothly are a breath of fresh air. It seems so simple, but it makes me so much more excited about this application.
3.) It’s extremely usable. The controls are simple and easy to find. The layout is focused on maximizing the screen area and provides a few basic controls to do everything else.
3.) It has a great website. Joost’s website is short, sweet, and to the point. The header features small flash movies that promote the application in entertaining ways and the content itself is concise. Rather than trying to be all things to all people, it’s one thing: a website that tells you about Joost.
The bottom line with applications like Joost is that they emphasize elegant usability. It looks great, but it’s not cluttered or confusing, and at the end of the day, that’s the single most important thing separating good ideas from popular software.
Joost doesn’t tell me how many invitations I have left, but as of right now I can still send invites. If you’re looking for one, add a comment with your email address and I’ll get it sent to you ASAP.
I gave a presentation earlier this week online for Adobe on using Flex Builder 2. If you’re new to Flex or wondering whether Flex Builder is worth using, it might be helpful.
This was the first time I’d given this presentation, so it went a little long. We also had over 100 attendees, so the question and answer time was absolutely crazy. The text area where I as the presenter was reading the questions from was scrolling so fast I could barely read it!
You can find Adobe’s recording of the presentation here.