My JavaFX 1.2 Blogging Contest Submission, by Sten Anderson
Friday, July 3rd, 2009
The JavaFX team is running a contest for blogging about developer experience with the newly released 1.2 feature set. The top 10 posts each receive $500 USD. This blog post is my contest submission.
—————-
Let me start by saying thank you to Sun Microsystems for sponsoring this contest, and to the JavaFX team for crafting such a fine RIA development platform.
Finally, I’d like to extend a very heartfelt “thank you” to the judges of the contest for reading each and every submission. I don’t envy the position you must be in, having to cull through each submission — each one chronicling a developer’s story, because while deep down we’re all winners, in a more accurate sense, only ten of us are.
Indeed, what does a $500 blog entry even look like? I imagine it must be bursting at the seams with insight and purpose. So while I have no doubt that you, the honorable judges, are up to this daunting task of discernment, I trust that the $20 I’ve forwarded to each of you will aid in the decision making process.
Actually, I’m feeling pretty good about my chances here, since after all, this is a blogging contest, and they don’t give out blogs to just anybody (case in point: I was put on an 18 month waiting list for this blog). So unless you’re accepting handwritten submissions, this is likely a slam dunk. But don’t worry — I’ll still take it seriously (wink).
So let’s get to it, shall we? JavaFX 1.2: The Developer Experience!
There are so many earth-shatteringly new features in the 1.2 release, it’s hard to know where to begin. Let’s start with the most obvious surprise addition: Charts. The charting support in JavaFX 1.2 is awesome! Just awesome! I love it.
Let’s see, what’s next? Oh, I know! All of the new controls! The new controls are AWESOME! Just really great! And they look stupendous in the new Look and Feel, Caspian. Good stuff. Love it.
Ok, covered that…what’s next? That might be it, right?
Ok. So, here’s the deal: I haven’t actually downloaded JFX 1.2 yet, but I promise that I will real soon. In fact, on that note, perhaps $500 would (ahem) speed that process along a bit, if you know what I’m saying…and I think you do. Just crown me as one of the winners and then I’ll promise to write up a more thorough post at a later date, ok?
Ok, fine, we’ll play by your rules. Let me download it and check it out. Don’t go anywhere.
[Many days later...]
Ok, so, I’ll devote the rest of this entry to my experience with migrating a JavaFX 1.1 application, Music Explorer FX, to 1.2.
The first thing that I was confronted with upon loading up the Music Explorer Netbeans project for the first time in 1.2 was the massive number of overly-apologetic compiler errors. After about the hundredth “Sorry, but I was trying to understand…”, though, I was starting to suspect its sincerity.
Perhaps you guys want to consider implementing an “Incrementally Irritable” Compiler where the first 10 or so errors nets you a polite “Pardon me, but I think you erred”, but by the, say, 50th error, you’ve degraded into a “bitch, plz!”
(Note: the contest guidelines likely have anti-profanity rules which you might be tempted to invoke to disqualify me after my use of the word “bitch” above. I would argue, however, that while “bitch” is a indeed a coarse term, it was used in a humorous way, which I’m sure elicited at least a smile, if not a full blown “lol” (if neither, then you must be finding this post torturous to wade through, but might I remind Your Honor that you took an oath to read each and every post in this contest. You have to finish.) Besides, “bitch” is not profanity according to WikiAnwsers.)
Anyway, these errors weren’t a surprise as I did read up enough on the 1.2 changes to expect them. After comma separating my sequences and changing all my “Image.fromBufferedImage” to “SwingUtils.toFXImage”, I was building successfully and ready to run the application.
When I bring up the application, though, I just get a black screen, so something isn’t right here. After some digging it turns out that I was binding to a Group on the Scene, which, while it seemed to work in 1.1, doesn’t seem to in 1.2. No worries though. So I simply removed the Group and did a bind directly to the underlying sequence and things start up normally again.
Great. So overall a pretty painless migration to get the app running again. Let’s see if the application still works though.
Oops. When I try to search for an artist, I get the following exception:
Exception in thread "AWT-EventQueue-0" java.lang.ClassCastException: com.sun.javafx.runtime.sequence.ObjectArraySequence cannot be cast to com.citytechinc.ria.musicexplorerfx.model.Artist
The exception seems to occur when I pull data (a Sequence) from the Java layer back up to the JavaFX layer. In my attempt to futz with some of the return types to get this cryptic exception to go away I run across this Jim Dandy:
Note: An internal error has occurred in the OpenJFX compiler. Please file a bug at the
Openjfx-compiler issues home (https://openjfx-compiler.dev.java.net/Issues)
after checking for duplicates. Include in your report:
- the following diagnostics
- file C:\Documents and Settings\sanderson\Local Settings\Temp\ javafx_err_2753540138989817596.txt
- and if possible, the source file which triggered this problem.
Thank you.
Oh my! That seems like a rather serious error. You’d probably really like to get your hands on “javafx_err_2753540138989817596.txt” I bet. Perhaps $500 might help it find its way into a bug report.
But I kid! This whole “sequence across the Java layer” issue is bugging me though, so I tried to simply and isolate with a small test case. To that end, here’s a simple JavaFX class called ValueObject:
public class ValueObject {
public override function toString():String {
"Value Object";
}
}
Here’s a simple Java class representing the Java layer:
public class JavaLayer {
Object doNothing(Object obj) {
return obj;
}
}
All it will do is take an object from JavaFX and return it. Here we put it together in a separate JavaFX script:
var seq:Object[];
insert ValueObject {} into seq;
var javaLayer = new JavaLayer();
var javaSeq = javaLayer.doNothing(seq);
var javaObjSeq = javaSeq as Object[];
for (element in javaObjSeq) {
var val = element as ValueObject; // throws ClassCastException
}
We insert a new ValueObject into a Sequence, pass it to the Java layer, which does nothing but pass it back to us. Somewhere in this translation between boundaries, though, some sort of type information gets munged since the cast to ValueObject in the “for” loop results in this:
java.lang.ClassCastException: com.sun.javafx.runtime.sequence.ObjectArraySequence cannot be cast to seqtest.ValueObject
I would expect “javaObjSeq” to be of type “ObjectArraySequence” (it’s actually of type SingletonSequence, which makes sense since it has one element — btw, a quick naming suggestion on “SingletonSequence”: it might make more sense to name it “SingleElementSequence” so it doesn’t clash with the name and intention of the “Singleton” design pattern), but it turns out that its contents is also of type “ObjectArraySequence”, even though, if we ask “element” to print itself, it prints “Value Object”, which indicates that it is in fact of type “Value Object”.
So this is very confusing to me, be it a bug or a misunderstanding on my part. At any rate, something changed between 1.1 and 1.2 here.
Leaving the mundanity of data transfer issues behind us, something else I was able to do was upgrade some of my wrapped Swing components to official JavaFX 1.2 controls. You can consult this post for more details. In fact, in all fairness that post should also count towards the contest as well since it’s all on the same theme. Alternately you could consider it a double-entry if you feel that both posts taken together deserve a double prize of $1000.
Whew, so I’ve kind of run out of steam and time on this migration, as I’m sure you, dear judge(s), have run out of patience. This contest ends today, which for me, is a day off, and my two children are asking me to repair the pillow fort that I made for them out of the couch cushions not 20 minutes ago. And since, I think you’ll agree, that the central message of JavaFX is really that of a harmony between not just developer and development, but also between developer and life in general — including family life — that you’ll forgive me for ending this (I can only hope) award-winning post prematurely.
User or Usability? (or, The Psychology of Software Support)
Friday, June 26th, 2009
Before going into Software Engineering, I took a job in PC support at the university from which I graduated where it was my job to answer the support questions of the professors and administrative staff. I quickly realized that my job had very little to do with any sort of proficiency with technology as it did with simply being a sink for raw human emotion.
A veritable “who’s who” of the emotions involved in grief, I’ve seen a professor indignant and rage filled over the news that a crashed computer and unsaved document added up to hours of lost effort.
I’ve tried to console a staffer in tears over the embarrassment and despair of her 10th support call over Excel, whimpering, “I just don’t get it. I’m just no good at this!”
I’ve witnessed the bewilderment and denial of a PhD at the words of his document all running together: “I don’t understand, I’m pressing the “shift” key to shift the cursor over”.
My heart goes out to these people — technology is harsh and unforgiving (although in fairness, the “technology” of the space bar has been around at least since mechanical typewriters).
I would imagine that most users spend a not insignificant percentage of their time on a computer in some sort of troubleshooting mode. I actually enjoy working with computers, so my patience threshold for futzing around with something I don’t understand is probably higher than average — but woe to the user who actually doesn’t want to sink hours of time into learning how to use a new program.
It’s easy to point to the end user as the one at fault, but I think this is a mistake. I think more often than not, it’s a usability problem, not a user problem.
Usability is a fragile thing. We like to label programs as “intuitive”, but they are only that way because we’ve been trained on what to expect from previous programs. So when we say that a program is intuitive, we really mean that it conforms to our expectations — expectations that have been formed by the evolution of programs which have come before. But when a program behaves in an unexpected way, our confidence in its use is rattled, and we become adrift in its apparent arbitrariness. What was intuitive for its designers turned out to not be so for its users.
Usability Expert Jef Raskin warns against the flippant use of “intuitive” to describe interfaces:
“The impression that the phrase “this interface feature is intuitive” leaves is that the interface works the way the user does, that normal human “intuition” suffices to use it, that neither training nor rational thought is necessary, and that it will feel “natural.” We are said to “intuit” a concept when we seem to suddenly understand it without any apparent effort or previous exposure to the idea. In common parlance, intuition has the additional flavor of a nearly supernatural ability humans possess in varying degrees. Given these connotations, it is as uncomfortable a term in formal HCI studies as it is a common one in non-technical publications and in informal conversation about interfaces.”
He goes on to note that we should more accurately favor the word “familiar” over “intuitive”.
So really, when users are at the mercy of support it’s not because they lack intuition, a word that is connotatively linked to intelligence — it’s that they lack familiarity.
The person questioning her own self-worth over Excel may be in the wrong profession — or perhaps Excel is not all that intuitive. Excel in particular is an extremely powerful, and complicated program, one that, for some reason, is present on most machines in corporate America. Given its ubiquity and unusually broad user base, it needs to pay particularly close attention to usability.
One way a program can make up for being complex is by encouraging the user to explore and try out features knowing that they can always back them out with “undo”. In my experience Excel is particularly bad at this, not because it implements “undo/redo” poorly, but because it is such a complex and bloated program that it needs to go above and beyond conventional “undo” semantics.
I’m continually surprised, when after futzing with charts (or whatever), making changes and having “undo” disabled: “Can’t undo”. Can’t undo? Why not? I just modified the state of the document — back out my changes, Excel! Don’t make me Revert To Saved!
Now that I find myself on the other side of the curtain of application development, I try to be mindful of the user on the other end. When I watch people use an application I’ve written and they struggle with how to do something, my gut reaction is that it’s a training issue.
But it’s not. Ever. It’s a Usability Fail, and it means that I need to listen to the users, and try again.
UPDATE: So, in some sort of odd cosmic coincidence, Hamlet D’Arcy has written about almost the exact same topic a few days ago (although somewhat unbelievably I didn’t notice it until after I posted this). He even quotes Jef Raskin! So go read his post too.
Faking a Password Field in JavaFX 1.2
Tuesday, June 23rd, 2009
I’ve been slowly attempting to migrate The Music Explorer from JavaFX 1.1 to 1.2. One area of the application that I was particularly looking forward to updating was the Twitter panel, which is the set of UI components that let you automatically Tweet your activity using the application.
Here’s what it currently looks like in the 1.1 version (on Windows):
It’s not exactly my proudest design moment, and if you haven’t checked out the Music Explorer yet, don’t let this deter you — it is visually the weakest part of the application.
In my defense, it looks this way because it mixes Swing components and JavaFX controls which made it all but impossible to line things up correctly. The second text box in particular is a wrapped Swing JPasswordField, which is unfortunately a slightly different size than the plain JavaFX text control above it.
“Oh, come on now”, you say. “It’s not that bad”.
Fine, check out how it looks on the mac:
Enough said.
So, clearly this needs its own sort of Extreme GUI Makeover: JavaFX 1.2 Edition.
Here’s what it looked like after I compiled it under JavaFX 1.2 (with no code changes):
Oops. That looks much worse, although I like the blue highlight and visible cursor in the new text control. Clearly, though, Swing and JFX Controls are just not going to get along - ever. So after replacing all the Swing components with 100% Certified JFX Controls and Layout Managers, here’s what it looks like:
Much better. Notice the “prompt text” on the text controls which solves the lack of labeling problem.
So now the hard part in all this of course, is that the second text box is a password field, yet since JavaFX still doesn’t currently have such a widget, anything typed into that field will show up as clear text.
So this problem jogged my memory to a post on Drew’s Blog (which btw, is a great source for quality JavaFX posts) who solved this problem by blurring the contents of the text field. Since that’s a pretty neat idea, I went ahead and did that here:
And here’s the code that makes that happen:
TextBox {
promptText: "Password"
columns: 15
effect: bind if (password.rawText.length() > 0) BoxBlur {} else null
}
Note that the password field isn’t blurred until the user starts typing, which means that if the “prompt text” is visible, it’s not blurred.
This relies on a couple of (perhaps shaky) assumptions to work. The first is that, according to the API docs, the value of “rawText” will be updated with every key stroke if the underlying system supports it otherwise it won’t be updated until the user “commits” the text (by navigating off the field for example). Meaning that it’s possible on some systems for the “blur” to not kick in until the user finishes typing (which would miss the point of obfuscating the password).
The second potential code smell here is a possible performance issue with the bind. I don’t know the mechanics of how the bind works, but if it gets evaluated every time “rawText.length()” changes (as opposed to the entire expression “rawText.length() > 0″, which will only change once), then it will get fired every key stroke. This might be alright though, if assigning the “effect” is an inexpensive operation (which I assume it is).
Another way to do this could be to register an “onKeyPressed” handler which would simply assign the effect on the first down stroke.
So there it is. Thanks again to Drew for the idea.
Dumbing Down Our User Experience
Sunday, June 21st, 2009
If a genie offered to give you some incredible super power, say the gift of flight, or invisibility, but in return would chop your IQ in half, would you do it?
What if he said that, over time, you’ll recover most of your intelligence to a point, but you’ll never be quite as smart as you are right at this moment — would you do it now?
About 12 or so years ago it seems like we were approached by the Web Genie, who offered us the fantastic promise of being able to use an application from any computer connected to the internet — no installation necessary!
All we would have to give up in return is any sense of usability to which we had grown accustomed. Sure we would gain it back slowly, but even 10 years later, web apps would still be struggling to be as usable as the most modest Visual Basic applications of the late 90s.
The first web apps in this pre-AJAX world held the novelty of filling out forms and pressing buttons in our browsers, at the expense of redefining our expectations of usability. But who needs usability when we’re bidding on small household appliances? Just take my credit card number and give me my toaster!
Then AJAX came around and set us back another five years in usability. Sure AJAX made web apps somewhat more usable if used correctly, but it meant that instead of returning to rich application development, we were going to try and keep at this web thing a little longer yet.
Web advocates proudly strutted the improved usability of their applications which we only accepted because our expectations were so low from the first generation of web apps. Suddenly Gmail looked amazingly usable compared to HotMail. A full page refresh on every operation? A thing of the past! Meanwhile, rich clients like Thunderbird silently wept in the corner.
It was similar to, in the early 90s, when popular music abruptly shifted away from Bands with Skill to the Grunge movement. Guitarists everywhere simultaneously recoiled at the notion that “Smells Like Teen Spirit” was the new standard, and rejoiced that the bar was now set so low since being in tune was now optional. It wouldn’t be until Guitar Hero brought back into the cultural awareness the reminder that Kansas is a pretty kick-ass band, and that guitar solos in songs aren’t optional.
Web Apps tend to struggle with fulfilling some basic rules of usability — basic maxims that Jef Raskin championed, such as, applications must treat all user input as sacred and, always allow the user to undo an operation.
We take it for granted that we’re not supposed to hit the “back” button at the risk of double charging our credit card, to say nothing of navigating to a different page, or abruptly closing the browser. We’re annoyed, but not surprised, when a form that we’ve spent the last 15 minutes filling out mysteriously resets itself after we submit it. We commit an operation, but we have no expectations at all that we will be able to undo what we just did.
I don’t know how many email drafts I’ve lost to Gmail because it got stuck in an unrecoverable “auto-save”. While editing a web page on “Google Sites” I am not uncommonly confronted with the message: “Unable to save the page at this time, please try again later”. Please try again later? I want to save my work now, not later!
We would never let a desktop application get away with this, but we grant a free pass to web apps because we understand that they’re shackled by the browser and pesky security models that don’t allow access to local storage, so we grant them copious amounts of slack, even though I’m sitting here with gigabytes of empty storage space and a document that can’t be saved.
As an internet consumer, I, of course, make liberal use of web apps all of the time. At the risk of biting the hand that feeds me all of the convenience of paying my bills or buying movie tickets without having to mail a check or talk to a person at a ticket counter, I am grateful for it all. I gladly accept convenience over usability with only mild amounts of grumbling.
It’s not like I haven’t produced my own usability nightmares on the desktop, or that there aren’t stand-out paragons of usability on the web. The distinction lies within the intention of the toolset that us mere mortals are expected to work with.
When I’ve committed my usability atrocities on the desktop, I had to go out of my way to buck the toolset I was using (I don’t, know, maybe I thought I was being clever), and conversely, the web developers that created, say, Google maps (since I’m on such a Google theme here) must have moved Heaven and Earth to make that work. One can only imagine what they could have come up with using Desktop technologies (it probably looks something like Google Earth).
So having said that, I find it difficult to get around the sentiment that web applications dumb down our expectations of what we’ve come to expect from how an application should behave. That might sound like an incendiary statement, and you might be tempted to think of this as just a tirade against web applications.
In fairness though, User Experience certainly does not make up the entire enchilada of what makes a quality application, just as the Nintendo Wii is proof that High Definition visuals aren’t necessarily for a quality gaming experience.
“Convenience and Collaboration” are huge driving forces behind what can make a Web application great (and I am a big fan of many of them). However, while “The Legend of Zelda: Twilight Princess” is one of my favorite games, I can’t help but wonder how much better the experience would have been in 1080p.
One of the Java Posse, in a discussion about how to distinguish a web app from a rich internet app,etc. stated that the distinction is moot: “it’s just apps”.
Perhaps this is extremely forward thinking and will be true ten years from now, but for the present trying to erase the line between the two types is what leads us to “The Uncanny Valley of User Interface Design”, as outlined in Bill Higgins’ excellent post. In a nutshell: web apps should conform to a user’s expectations for how a web app should behave, and vice versa for desktop applications. When the two cross into each other’s paradigms, a jarring, off-putting experience is the result.
Indeed it seems to be the trend for web apps today: move as many desktop-isms into the browser as possible banking on the fact that the user will appreciate inconsistent “auto-save” over none at all.
I wonder though, if we aren’t pushing in the wrong direction. Surely this web technologies thing can be taken further…but maybe it shouldn’t. Maybe it’s time to stop squeezing more “features” out of AJAX and get back to our rich client development roots.
Maybe we can remember that there was a time when not every application ran out of a browser.
JavaFX Project Postmortem: In Which I’m Interviewed by a Five Year Old
Sunday, June 14th, 2009
Developer magazines sometimes are able to interview key developers of high profile projects after they’ve been shipped (with questions such as “what went right?”, what went wrong?”, etc.). Since I officially kicked my first non-trivial JavaFX application, Music Explorer FX, out of the door last week, I figured that I would grant an interview of my own. Since my five year old daughter, Meredith, had refusal rights from her last interview (and also since she was the only one interested in talking to me), I happily granted her the honor.
Meredith: Thank you for taking the time to talk to me, daddy.
Me: Thank you for staying up past your bedtime to do this interview.
Meredith: Let’s get started, shall we? Tell me about the application you just finished.
Me: Music Explorer FX is a tool for music discovery, written in JavaFX. You can get more information at www.musicexplorerfx.com
Meredith: Yes, yes. Let’s keep the sale pitch to a minimum, please. So why did you choose JavaFX for this project?
Me: Well, I was looking to do a project in JavaFX, so in some ways it’s a backwards answer to the question–
Meredith: Well, you wrote the questions, I don’t even know what half of these words are…
Me: Yes, well, so the reason I was looking to do a project in JavaFX is because I’m primarily a Java developer, and while JavaFX syntax has no similarity to Java’s, JavaFX compiles down to regular Java class files that run on the JVM, maximizing interoperability with Java code. This means that I was able to use familiar core Java API classes, such as Map, and List, and even dip down into Java code as needed, for example, if I needed to work with threading. It also meant that I could freely use any existing 3rd party Java libraries, such as Twitter4j for the Tweet support.
Meredith: (laughs) Tweet! Like a bird! Tweet, tweet, tweet! Look at me! I’m a bird!
Me: Yes, yes, try to stay focused, sweetie.
Meredith: So you didn’t find the learning the language syntax much of a problem?
Me: No, not at all, while there are some oddities to the language, for example, capital “Void”, instead of regular “void”, overall its declarative syntax was very straightforward. JavaFX has been described as a DSL for User Interfaces and Animation, and I think that’s a good description for it. It actually shares a lot in common with Groovy Builders — the subject of our last interview.
Meredith: I don’t remember that.
Me: You were four at the time — your memories won’t start fully forming for a while yet.
Meredith: If you say so. So, JavaFX is a Rich Internet Application technology. So is it in my Dora the Explorer game on the computer?
Me: That’s probably Flash based — a JavaFX competitor.
Meredith: Oh, ok. So what are some JavaFX games I would have played? Sesame Street? Elmo’s World? The Backyardigans? Polly Pockets?
Me: Well, I mean, JavaFX is still very new. So “competitor” might be a little generous — and besides, I don’t know that JavaFX is targeting the casual game space per se.
Meredith: Uh huh. Let’s move on. Earlier today you gave Holly more ice cream in her cone than you gave me. You said that you’d make it up to me next time. When will that be exactly?
Me: Hey! I told you, I didn’t want to take any questions on Family Dessert Policy!
Meredith: Daddy! It’s not fair! You always give her more than me!
Me: Ugh. Fine. Do you want some ice cream now?
Meredith: Now? It’s two hours past my bedtime. You’re keeping me up pretty late as it is. If mommy finds out–
Me: Fine, fine. How about for breakfast tomorrow then?
Meredith: Deal. Well, I think that’s all the time we have.
Me: Wait, we’re not even halfway through the questions. Ask me how it felt to see my application on stage at the JavaOne keynote–
Meredith: Mommy!! Daddy’s keeping me up!
Me: Ok! Ok! Alright. Geez. We’re done. Ok?
Music Explorer FX: A Tool for Music Discovery Written in JavaFX
Wednesday, June 10th, 2009
So as I mentioned last week, in my exploration of JavaFX I’ve written a music discovery tool called “Music Explorer FX” (or just MEFX for short).
It’s been available for about a week now in the Java Store, but since that’s only available within the U.S. and requires registration, I’ve provided a link here. Just click on the “launch” button and you’ll be on your way.
Hopefully the application is somewhat self-explanatory, but here’s a very brief rundown of how it works.
Given a initial seed artist, which is entered in the initial search screen here, MEFX will present you with up to six artists that are similar. Click on any of these recommended artists to promote it to the center and start the process over. As you browse through artist recommendations, your old artists will be remembered along the top in the “history” that you can always return to at any point.
Once you generate a few artists in your history, you can tweet your musical journey by clicking on the the twitter icon (the singing bird) in the upper right corner.
At any point the artist in the middle (the “current” artist) will have a bank of buttons below it which you can use to jump between different modes of the application. From left to right they are:
- The search button takes you back to the initial search screen.
- The “info” button will show you various aggregated information from around the internet (e.g. news, reviews, artist homepage, iTunes link, videos, and blogs). You can click on any of the links in this mode
- The “image gallery” icon will attempt to pull down images of the artist performing live from Flickr (I’ve always enjoyed seeing live shots of bands for some reason).
- The “similar” button (visible only in “info” or “gallery” mode) will return you to the “artist similarity” screen.
- The “?” icon will bring up a basic help menu describing most of this information.
If audio is found for the current artist, audio controls will appear below the artist’s image.
The green and yellow gauges in the picture above are familiarity and hotness ratings respectively. Check out this post by Paul Lamere for a detailed explanation of these metrics.
You can run the application in full screen mode by clicking the icon in the lower right corner (full screen mode with dual monitors may cause unpredictable results). Click the icon again to return to windowed mode.
MEFX is largely powered by the Echo Nest’s public web services which provides the data for resolving the artist search, artist similarity, familiarity and hotness, any audio tracks, videos, blogs, news, links, and reviews.
Secondarily the artist profile images are courtesy of Last.fm’s web services, and the “image gallery” is feed by Flickr.
You can get more information about MEFX, including basic support information as well as more detailed instructions, at http://www.musicexplorerfx.com.
Special thanks to Paul Lamere, the Director of the Developer Community over at the Echo Nest, for help and support in getting this application off the ground. If, in using this app, you find yourself discovering new music — you have the Echo Nest to thank, not me.
Also thanks to my wife, Deb, for help with the artwork, and to my boss, Matt, for letting me run with this idea.
So anyway, if you do decide to try it, let me know what your experience is by leaving a comment or contacting me directly at sanderson att citytechinc dott com.
And if you discover a cool musical journey, hit that twitter button and share it with the world.
Enjoy!
JavaOne, Day 3: In Which I Shamelessly Plug My App at the Pavilion
Tuesday, June 9th, 2009
And now, the thrilling conclusion to my untimely JavaOne coverage…
The New World: JavaFX Technology-Based UI Controls
Finally! This standout session on the new controls offered in JavaFX 1.2 is exactly what I was waiting for. Delivered by most of the same team as the previous day’s unfortunate Extreme GUI Makeover, they launched right into showing the new Look and Feel, Caspian, citing Nimbus as having a dated look.
The new Look is really sharp — you could easily mistake it for a Flex app (which is a compliment).
The list of controls includes such UI staples such as Button, Checkbox, ToggleButton, Textbox, Slider, Scrollbar, Hyperlink, List, Progress Indicator, and even Charts.
Yep, charts are part of the core API — something Swing always had to defer to JFreeChart. This isn’t just one token bar chart either. Available types of charts include: bar (2d/23d), line, plot, pie (2d/3d), scatter, bubble, and area.
The more banal controls seem to have received a good amount of love by the team as well. They have several, subtle bits of polish that help make them feel like professional controls. For example:
- The text control has a “prompt text” attribute which shows up as gray initial text in the box (e.g. “Search” in a search box).
- The list widget allows for variable row height.
- The progress indicator in indeterminate mode is represented as a spinner.
It’s true that there is no Table/Tree widget, or even a Combo box, but the team was quick to say that another release was on the way “in about six months”.
Eventually long time Swing veteran, Amy Fowler, took the stage and went into the details about the new layout managers, including: Tile, Flow, HBox, VBox, Stack, and Panel. Of special interest (to me) was an offhanded comment she made along the lines of “the 2D, and eventually 3D scene graph”. Exciting. I love me my 3D.
I got the impression that I was one of the only JavaFX fanboys in the room, as there were epithets flying around to the effect of “How do you expect us to work without a ComboBox!?”, and “I can’t feed my family without a table widget!”
I’m willing to grant the JavaFX team the benefit of the doubt here. It’s possible that my expectations were simply just lowered by the previous two days’ sessions, which perhaps was part of the plan all along in order to make this session shine. But JavaFX was released just over half a year ago, so considering this, they’ve made some pretty impressive strides. So color me excited.
But enough about technical sessions. Let’s go to the Pavilion.
The Java Store had a corner of “Java Utopia” this year, where various members of the Team JavaFX were milling about ready to assist in your first chaperoned experience with the store. As mentioned previously, a JavaFX app that I authored, Music Explorer FX, was one of the inaugural apps in the store, so naturally, I wanted to hang out a bit and hear about people’s experiences with it.
If you’d like to try Music Explorer FX out for yourself, you’re free to sign up for the Java Store’s beta program (free registration), and then the application itself is, of course, free. Eventually the Java Store will be open to the public without the need to register, but as this may be a while yet, I’ll provide an easier way to download the application real soon now.
JavaOne Postmortem
The JavaOne t-shirts this year had the equation “Java = Opportunity” written on the front. As I stand in line to board the plane waiting for my Xanax to kick in, I can’t help but wonder if the word “Missed” additionally belongs after the equal sign.
JavaFX (and JavaOne in general) faces an uncertain future with the Oracle acquisition. This should have been JavaFX’s year at JavaOne to come into its own. Every JavaFX session should have been as good as the one I attended today, but instead I found the sessions plagued with two year old demos, confusing pairings (two Ajax guys defending JavaFX?), and abysmal performance ($200 for a JavaFX mobile device that will bring back the nostalgia of the AWT circa 1998). Speaking as someone who has devoted some of his professional self to this new language, I really do hope it can succeed in spite of itself.
Actually that’s a bit too poetic. Really what I’m thinking while waiting to board the plane is if I get out of line right now and go rent a car, and just drive straight through on I-80, I’ll be back in Chicago on Saturday with enough time to still see my daughter’s ballet recital.
JavaOne, Day 2: In Which the Tension Between JavaFX and Groovy Becomes Palpable
Sunday, June 7th, 2009
Here’s the next post in my series of increasingly untimely coverage of JavaOne.
Wednesday’s theme for me was all about user experience which started with…
Extreme GUI Makeover
Extreme GUI Makeover is a JavaOne favorite. I thoroughly enjoyed last year’s version, delivered by Ben Galbraith, which covered the case study of converting a Cobol application to a Swing Application (something I happened to be actually doing at the time).
This year’s iteration of the talk was delivered by a panel of speakers, I think (but I’m not positive) all members of the JavaFX team. This year the team scaled back the ambition and tackled the unimpressive task of converting some of the elements of a Swing Email Client to JavaFX.
The team outlined how they had to roll their own components in some cases to make up for JavaFX’s lack of maturity. For example, even though Swing has a perfectly fine JTree component (and SwingX has an even better one), they replaced it with a custom-made collection of nodes that behaved tree-like which bought them the ability to add fancy tree node transition animations.
The highlight of the talk (as judged by the amount of audience clapping and time spent explaining the feature) was the button that moved an email from the inbox to the junk mail folder. Instead of simply moving the message as most email clients do, this application would launch a missile sprite from under the button, which would follow a spline and culminate in incinerating the message on impact.
The feature was clearly meant to show JavaFX’s prowess with animation, path generation, and transitions to tie it all together. I had a hard time deciding, however, if every time a missile obliterated a message, the audience giddy with delight, if it was the message going up in flames, or my faith in JavaFX’s future.
I have a good deal of respect for the JavaFX team; they have accomplished much in a short about of time. Additionally they are good speakers capable of delivering quality sessions (as evidenced by a session on Day 3 which I’ll get to in the next post).
Having said that, I find trends like those present in this session very disturbing. JavaFX is trying to gain traction as an enterprise grade language, but as long as we’re blowing up messages in our inbox I imagine it will never be taken seriously.
And note that this is coming from the guy who wrote the Orangalzer.
Creating Compelling User Experiences
If Ben Galbraith woke up one day and decided to start a conference called BenOne in which all he did was talk about his day, I would be the first in line for registration. This guy knows how to give an interesting, thoughtful talk.
A lot of what makes Ben so effective as a speaker is in the subtleties of what he says. Rather than simply barrel through a list of bullet points, he takes the time to construct an argument, and support his points from multiple angles, all the while acknowledging differing points of view.
Last year’s “Compelling User Experiences” session was the most popular of the conference, and with good reason. This year’s talk, emphasizing craftsmanship this time, was once again easily my favorite.
Unlike other sessions, where I might walk out with several action items, or technical tidbits to try out, “Compelling Experiences” leaves me with nothing tangible, but rather a increased sense of awareness about how I approach my job. It encourages me to take a step back and helps me remember why I’m doing this stuff in the first place.
The gist of his talk is available on his blog. You owe it to yourself to check it out.
Pro JavaFX or Something Like That
(sigh) See “missiles” above.
Griffon BoF (Birds of a Feather)
The Griffon guys are making great strides in this much anticipated (by me anyway) “Grails-for-Swing” framework. One of the side notes of the BoF was the herculean effort put in by Geertjan Wielenga in creating a workable Griffon plug-in for Netbeans mere hours before the conference. Be sure to check out Scott Davis’ interview with Geertjan over at Thirstyhead.
Actually, Scott Davis, known for his infectiously charismatic love of Groovy which is impossible to resist, interviewed the “who’s who” of the Groovy world while at JavaOne, including Andres Almiray, Dave Klein, Graeme Rocher, Dierk Koenig, and Mr. Groovy himself, Guillaume Laforge.
Incidentally, I had a chance to speak with many of these guys informally myself, and I was (and continue to be) impressed by their approachability, genuineness, and sense of community. The Groovy community is indeed in good hands.
Whew, so almost done. Be sure to keep an eye out for the thrilling conclusion of my untimely JavaOne coverage…
JavaOne, Day 1: Sessions
Friday, June 5th, 2009
Here’s a breakdown of some of the sessions that I attended on the first day of the JavaOne conference. I meant to get this out in a more timely manner but it turns out that I’m no good at spontaneous posting.
A conference like JavaOne has an overwhelming number of technical sessions, labs, panel discussions, and vendor booths. As a result, I often feel like I need to fight back the feeling of failure if I somehow don’t absorb it all.
To counter this anxiety I often remember the wise words of my good friend Linc (who is also the drummer of Hungry Fathers): “Instead of trying to be everything to everyone, try to be three things to seven people”.
So having said that, my “three things” generally are: Groovy, JavaFX, and Usability.
JVM Script Showdown (a.k.a. “Script Bowl”)
This session was intended to be a sort of “rapid fire” comparison of several JVM languages: Jython, Groovy, Clojure, Scala, and JRuby.
Of course the winner of the “showdown” really was predetermined by how much support for each language walked through the door (it was Groovy). In other words, it’s difficult to imagine any “blank slates” coming to the session and, after hearing 5 minutes about each language, forming a definite preference.
Although the sales pitch by the panelists did play a part, and to that point, Dick Wall (of Java Posse fame) deserves a special mention for his infectious love of Scala. He almost convinced me to step away from my predetermined vote for Groovy.
Almost.
Java Puzzlers
Listening to Neal Gafter and Josh Bloch is a good reminder that the most important part of a session is its speaker(s). This is evidenced by the fact that we were all riveted to what amounted to exploring corner cases of the java compiler. I think if Josh offered a session on what he had for lunch, I would still enthusiastically attend.
AJAX vs. JavaFX
Self-described as AJAX’s Hannity to JavaFX’s Colmes, Ben Galbraith and Dion Almaer, both AJAX advocates, debated the merits of the two development platforms. Having thoroughly enjoyed Ben’s two sessions from last year’s JavaOne, I wasn’t surprised to see him excel in his element: defending the web platform.
While Dion very aptly defended JavaFX, it was odd that they weren’t able to wrangle up someone who actually believed in the merits of JavaFX over AJAX (doubly so given that this is a conference about JavaFX).
Some memorable fighting words from Ben (somewhat paraphrased):
- “JavaFX seems like it was one guy’s idea at designing a language with no thought to compatibility.” (i.e. its syntax is unnecessarily different from Java making it difficult for Java programmers to learn). (My parenthetical aside: This is the most common criticism I’ve heard voiced against JavaFX. As a Java programmer I agree that it would have been nice if JavaFX was simply a specialized DSL of Groovy (bonus parenthetical aside: more of this particular point in a future post), and therefore easy to get up to speed in. My only response in JavaFX’s favor is that the language is targeted toward ActionScript developers, not Java programmers. Remember that JavaFX was originally acquired by Sun as the language F3 so (I assume) it had no thought to Java compatibility as its birth. I don’t know if that’s a mark in JavaFX’s favor as much as it is explaining away the question).
- Java fonts exist in the “uncanny valley“, something is always just a bit “off” with them as compared to native fonts.
Toward a Renaissance VM
This was mostly an explanation of the new JVM byte code instruction “invokeDynamic” with enough background provided so that a non VM engineer such as myself could (mostly) follow along. Of particular interest was a concise explanation of where the line is between Java the language and Java the Platform. Unfortunately this session suffered from “last of the day” syndrome, so the notes that I took are incomprehensible to me as I try to read over them two days later.
That does it for day one. Be sure to stay tuned for untimely session coverage of Day Two of the JavaOne 2009 conference…
JavaOne, Day 1: Keynote — A Labor of Love
Wednesday, June 3rd, 2009
I’ve already mentioned in a previous post what I found most exciting, from a personal standpoint, about the JavaOne Keynote. Indeed, the announcement about the Java App Store itself is cause for celebration. A central point of distribution would be a potentially great injection of vitality into an aging Java community.
At several points the mantra, “labor of love”, was repeated by both James Gosling and Jonathan Schwartz as a central driver for the app store. Indeed, this idea, I think, really does resonate universally with programmers. Every programmer (myself included) seems to have that side project (or collection of same) that if only others could see, might somehow take off and have a life of its own.
This idea really taps into the primal urges of coders — to create, but also to share. It really should have been the central message, delivered with all the pomp and circumstance that a keynote demands.
But that’s not the keynote that I attended. The keynote, rather, had a muted, melancholy tone, and an awkward sense of finality.
The first part of the keynote was devoted to a collection of Sun partners taking the stage and delivering various degrees of prepared comments about how a partnership with Sun is good and (sometimes obliquely) how Java is a big part of that.
Some of the partners included representatives from Verizon, Intel, RIM (whose phone unironically went off while on stage), and Sony, who at the utterance of the phrase “at a reasonable price” in reference to blu-ray technology made me feel like I had been sitting through a sales pitch all along.
Toward the end, Sun Chairman Scott McNealy, came up on stage to “address the elephant in the room”: the Oracle acquisition.
After some ambiguous language, with multiple citations of not being able to legally comment on “the details”, I ended up feeling more confused and unsure about the acquisition than had he not said anything at all.
Scott’s way of talking at some point seemed to place the blame on us with accusatory phrases like, “this shouldn’t come as a surprise to anyone” adopting the same tone I use when my two year old brushes her teeth with water from the toilet bowl.
Scott was eventually rescued by Oracle CEO Larry Ellison (”our new boss”) who came up on stage to reinforce Oracle’s commitment to Java.
At some point in this awkward reassurance, Scott turned to Jonathan (Schwartz) and “thanked him for being a great steward of Java” and closed with “this is the last JavaOne…that I will be chairman of”. It was a bitter sweet, pseudo-emotional moment which culminated in a standing ovation. It felt like an oddly private moment despite the other 20,000 people in the room.
I have great respect for McNealy and Schwartz and their accomplishments, but the keynote could have (should have) been a celebration of Java’s new life, as evidenced through the emerging app store and almost comically parenthetical asides of new versions of Java SE, Java EE, and Java FX. Instead, it had the feeling of looking back on “the good years” and an awkward passing of the Java torch.
