Posted by robogeek
on September 16, 2005 at 3:17 PM PDT
I just watched a long video shot by Scoble about the Sparkle product that Microsoft is brewing up. It gave me several thoughts to share.
But first, a coule links:
What is Sparkle and is it a "Flash Killer?" (arsTechnica review of Scobles move)
Manuel Clement and others - Introducing Sparkle (Scoble's posting on Channel 9 allowing the Sparkle team to demo the code)
My first thought is remembering a comment I heard at Java ONE a couple years ago. This was in a BOF about a technique for making animated cartoons that can be displayed on a cell phone. There was a lot of low level technical gruntwork there, such as a special image encoding due to the limitations of cell phones. But the speaker had a very good point he made.
It's great when the software tools match the needs of the person doing whatever task is at hand.
That is, a software coder has a different mindset and needs than the graphic designer. The sparkle example in the movie demonstrates this very well. When designing a user interface, whether it's in a web browser or a desktop application or a gaming box or whatever, you're gonna clash two worlds. Those two worlds are graphics designers and coders.
The world of coders is very textual. Software code is written as text, hence the part of our minds that gets exercised is textual. But creating graphics is hard from a software coders standpoint, speaking as one.
The world of graphics design is very different. It's a different mindset, different tools, etc. It doesn't work to give a graphics designer a textually oriented toolset because those kind of tools won't help them. They aren't oriented to their task. Likewise a musician needs to deal with notes, beats, chords, etc.
Hence, when you're developing your UI the team is speaking from different modes of work, and using different kinds of tools.
The other thought is, doesn't this Sparkle thing kinda throw out standard look and feel out the window?
Oh, and this applies very much to Java and Swing. One of the arguments against Swing is we've not done a great job with the application looking like a native application. Okay, that's a decent assessment and I can't argue very much with it.
However let me make an observation. The strict adherence to look and feel has been eroding over the years. On the Windows side the look and feel of applications has been varying all over the place. I'm typing this from my Mac OS X system, and I see windows in front of me using various look and feels. I have Safari and Windows Media Player, both using this brushed metal look. And I have terminal windows using the older lickable OS X look. I'm using Firefox right now with its attempt at the lickable OS X look. And I have some Java apps whose look and feel are something different.
And, with this Sparkle thing, the application designers can diverge even further from the standard look and feel. With Sparkle it's weaving wild graphics capabilities, both 2D and 3D, into the design of desktop applications. There's no way the result of Sparkle's capabilities is going to stay within any rigid lines of look and feel guidelines.
You could see this buried in the gleaming WOW'ness in the eyes of the Sparkle team.
Obviously Swing doesn't do what they're doing, and that's not my point. Instead my point is, doesn't the changing world say something about what Swing should be doing? Does it matter anylonger whether Swing is pixel-for-pixel matching the native look and feel standard? I see the wide variety of looks on the applications I use every day, and I think ... the user population has learned to cope with skinnable applications.
Of course there's a need to improve Swing. For example in Mustang we have a project to improve the readability of text rendering, making it more like native rendering. We'll continue to do those things just as we'll continue our effort to look like whatever the native look and feel is.
But as time progresses, and graphics support on desktop systems becomes more and more powerful, the OS vendors are building fancier display methodologies into their native look and feel. The native look is going to become even more divergent than it already has. I think the end user audience is going to become even more accustomed to dealing with applications using a variety of look and feel concepts.