One of the most visible effects of choosing either web or desktop technology is the way the resulting application will appear. Right now there are a couple of development frameworks to take into consideration. These are in no particular order:
- Basic web application
- Netbeans/Eclipse Rich Client
- Swing/SWT application
(This list is Java oriented.)
All of these have advantages and disadvantages. The list above can be divided into two main categories. To no surprise these are Web and Desktop. Anyway, right now I’m working for my employer on a document which ellaborates on these differences. Also I’ve submitted a proposal to the NL-JUG’s upcomming J-Fall to do a talk about this subject for my employer. I hope they’ll agree with me that it’s an important subject to reflect on a bit.
I came accross a great little Os X app today: djay The reason for blogging about this app is simple. Just look at the screenshot. It’s so intuitive it’s almost painfull. Wanna scratch a little, grab that record and work it out with your mouse. Next I was wondering how I could change the time index. There was no button or menu item anywhere. I was just thinking to difficult. Click on the arm and drag the LP player and you are changing the time index. You get suitable feedback at the top of the screen while handling the arm, the time index shows below the time remaining index.
Anyway enough of the fun stuff. My point is, this little app just clicks. The UI looks great and it you can control the application without a hitch in a very intuitive way. While it is just a little “app” (well, it does a lot of fun stuff with the Quicktime Framework under the hood), it’s an excellent example of taking a step back before creating a UI. The point is, think before slapping together another UI. It’s very important that a UI just flows and feels right.
While I’m not feeling very good today, I have a headache again, one can only stay in bed for so long. So while browsing around a bit (http://www.opensolaris.org/os/ to be exact).
I stumbled upon some very positive news from the Apple Word Wide Developers Conference (WWDC). According to ZD-NET Australia the next release of Apple OS-X, Leopard, will support DTrance. It also gets an Apple work-over, so it will probably look and feel good too. Take a look at the bottom of Apple’s Leopard preview page. Apple will include a tool called XRay which will leverage DTrace to provide its functionality. Knowing Apple this will probably mean that the original tool will be included as well.
For those who are wondering what DTrace is. Well, it’s a comprehensive dynamic tracing framework. DTrace provides a powerful infrastructure to permit administrators, developers, and service personnel to concisely answer arbitrary questions about the behaviour of the operating system and user programs.
“What?” you might say… well it comes down to this:
- dynamically enable and manage thousands of probes
- dynamically associate predicates and actions with probes
- dynamically manage trace buffers and probe overhead
- examine trace data from a live system or from a system crash dump
- implement new trace data providers that plug into DTrace
- implement trace data consumers that provide data display
- implement tools that configure DTrace probes
(Source: http://www.opensolaris.org/os/community/dtrace/, you can find a more detailed description of DTrace there as well.)
Let’s just say, seeing is believing. Once you see DTrace in action, you’re hooked.
Don’t buy this book. It’s only good for dead weight and lighting a fire. The book seemed so promising when I picked it up. Some guy’s views on interface oriented design. After some mandatory introductory stuff it goes bad. Real bad. It winds up into to a pizza laden interface convulsion where XML gets dragged in by it’s hair, topped with the most basic of basic remarks about why and how you should design by interface. Hell, it even grabs the Gang of Four by the balls to give it a little twist.
And I thought that “The Pragmatic Programmers” publishing stood for quality. Kind of like the way O’Reilly books are no-brainers (in good way) when looking for a book about a subject.
Don’t say I warned you when you buy this book. It’s that bad, I wont waste any more words on it. Now I’m of searching for my receipt in hope of being able to return this thing.
Finally you’ve finished your latest wonder. Now to boldly move on to marvellous new functionality.
Wait a second.
Before moving on to something else it would be nice of you to actually make your app available to your users.
Continue reading “Rich Client vs. Web 2.0 – Deployment and maintenance”
In my opinion a lot of companies are going to make decisions in the near future about using Web 2.0 or Rich Client for their next end-user applications. Both have their respective strong and weak points.
Over the next couple of weeks I intend to put up some postings about my opinion on various aspects of Web 2.0 compared to Rich Client development. Since I myself am mostly involved with Java software development I will focus on the aspects of frameworks and platforms based on the Java language.
For this intro, let’s lay down some basics by defining what Web 2.0 and Rich Client is.
I’ve found a nice definition of Web 2.0 at O’Reilly Radar:
Web 2.0 is the network as platform, spanning all connected devices; Web 2.0 applications are those that make the most of the intrinsic advantages of that platform: delivering software as a continually-updated service that gets better the more people use it, consuming and remixing data from multiple sources, including individual users, while providing their own data and services in a form that allows remixing by others, creating network effects through an “architecture of participation,” and going beyond the page metaphor of Web 1.0 to deliver rich user experiences.
Now on to Rich Client. There is a very good definition available at TechTarget.com:
A rich client is a networked computer that has some resources installed locally but also depends on other resources distributed over the network. The rich client’s configuration is somewhere between that of a thin client, which relies largely upon network-distributed resources, and a fat client which has most resources installed locally.
I just got home, and it seems everybody was happy with my presentation. I am relieved. 🙂
To the left you see an example of a slide, just to give you a taste.
I know, it looks cheap. But it got the point across. The “A-Team” font is a standard font on Mac OSX. It’s called Stencil.
Right now I am giving a presentation to my co-workers.
It’s about blogging at our company.
It involves a number of things:
- Baking cookies
- Mac programming
- Seven of nine
- BA Baracus
- Agent Smith
- Oh, lets not forget Naked Conversations
Curious? Let me know I’ll see what I can do for you. 😉
Normally I just don’t do it. I don’t like link blogs at all. But today Joel Spolsky posted something that is so true, it just plain hurts when you realise it. I just have to make an exception, because it aligns with my personal view perfectly.
Can Your Programming Language Do This?
This is true in the Netherlands too. All they teach/learn at comp-sci these days is Java or .NET. Such a waste, because these guys & girls get a degree without even having tasted or seen functional programming. There are exceptions. But most of the time, too bad.
Rest assured, I won’t go link whoring on this blog.