Why I hate ribbons

Ribbons are those fancy new toolbars of Microsoft Office 2007. I read an article a longer time ago from Microsoft telling that they did some survey before the release of Office 2007 to ask people what features they would like to have in the next versions. And it turned out that a very lot of features the people were asking were already there in 2003. This made them think about why the users didn't find those features that are already there. And that made them redesign the user interface.

In my opinion they made the first error already there: An application that offers many features can't be mastered fully by everybody. And people often do things as they were used to for many years. The only thing you can try is to get a good structure how your features are sorted and organized in the application so that people intuitively find what they are looking for - if they would look up (and many don't - just when you ask them what features they would like to have they start inventing and thinking).

• Ribbon bars are no guarantee for a well structured organization of program features.
  And indeed, Microsoft didn't organize many things well. For instance I do not know why the macros are under "View".
  
  
• Ribbons take more space than normal menus and toolbars.
  This might not be very important for big screen resolutions but when I use bigger resolutions and larger monitors I want to reduce the window size to see more windows and not one window bigger.
  
  
• Buttons are different sizes and according to Murphy's law those I need are tiny and those I don't are huge.
  Microsoft (or the appropriate software designers) decided about the size of particular icons in the bar. They adapted it to the desires of the mean user. But who is the mean user? This is a person that in reality does not exist. And so some button sizes can fit for some users.
  
  
• Ribbons are a replacement for toolbars and not a replacement for menus.
  When introducing ribbons Microsoft dropped the pull-down menus. But on the ribbons only a few features are displayed and many are hidden behind a very tiny button on the lower right. If they would just have dropped the old toolbars for the ribbons then I would have understood more.
  
  
• Buttons are not general in line.
  The buttons on the ribbons are not always ordered next to each other. Some are left and right others are above and below. This makes it more difficult for the user to get along.
  
  
• Ribbons are not customizable.
  Older Office versions had completely customizable toolbars. With the introduction of the ribbons this feature has completely gone.
  

These were just the general issues with ribbons and I am not talking about things that are Microsoft specific. For instance that behind the tiny buttons on the lower left you get to the old dialogs so that the ribbons are only facade.

Just a side note: There are free Ribbon components for Java (Flamingo) available (and I guess also for .NET although a quick search on Google only showed up commercial variants). So it is not a matter of inability to create such a GUI why I don't like them.

The IDE and the libraries

I followed a few discussions lately about Flex, Silverlight and JavaFX and also about the never ending war between the programming languages. Yes, we don't have a sufficient number of programming languages yet and therefore we need new ones - like D for instance. I am sure there will be born others in the future.

But aren't we missing the point? Aren't we trying to reinvent the wheel again and again?

I have seen people pushing languages and technologies one week and and another week something else without having real knowledge or without going deeper into the technologies to get aware of their real purpose. Same type of software is written again and again using different languages and technologies but where is the main additional benefit? Where is the improvement in efficiency while developing?

I have learned over 10 programming languages, really working for a longer time (on real-world projects making money) with about 3 languages. The experience shows it clearly to me, that the programming language itself is only plays a minor role in efficiency of software development. Much more important is the IDE and the libraries. In detail:

1. The IDE
   
   • Code-completion
   • Quick tips
   • Debugger (Breakpoints, watches, step-by-step-debugging)
   • GUI-Designer
   • (Online-)Help (or JavaDoc for instance)
   • Editing tools like bookmarks or tasks in code, code folding etc.
   • Refactoring tools
   • build tools (for compiling and deploying)
     
2. The Libaries
   
   • Standard libraries the language offers.
   • Available libraries on the Internet (opensource, free, commercial - the wider the field the better).
   • Your own libraries created while doing your work. The value of those is often underestimated although those include the code you usually do reuse most. And those are what I miss most when learning a new language - the stuff I already did and want to reuse and improve on the fly.

Both - the IDE and the Libraries have to be learned. So being familiar with the syntax of the langauge is one thing. Being familiar with an IDE and with the existing (standard) libraries is a second.

Fact is that one using a language he or she is not familiar with and then either using a simple text editor can never be as productive as a developer knowing the IDE and their features (and use them efficiently) as well as the existing (standard) libraries. When the latter also have a good overview about other free and commercial libraries or tools out there he or she can either efficiently decide where to write own stuff or use 3rd party components.

When I searched for an alternative to my Visual Basic I looked at several languages and the language itself was of minor priority. I liked Python for instance from the general language features and efficiency in coding I also imagine problems due to the indentation orientation when different developers use different editors with different indentation settings. But despite the language itself I tried several IDE's for python and there was none that I was really satisfied with.

Eclipse and NetBeans are IDE's that like to solve the IDE problem in general to be the one IDE for all languages. But from what I read and heard by now they work best for Java (and C++ - which I didn't try yet) so far (which is subject to change). But new languages usually lack of integration with good IDE's - logically.

So all this in a whole made me switch to Java (apart from the very good reason for platform independent development). - I do not urge anyone to use Java but I strongly recommend to not only look at the language itself when choosing a new one for future projects.

Related posts: IT investment, Utility libraries, Popular Java myths, Install NetBeans on Ubuntu 10.04, Choosing a programming language.

Homogeneous programming style

I am currently on the smooth move from Visual Basic 5 to Java (for new projects). Although I did also some PHP and ASP my focus was on Visual Basic and VB Script for the last about 12 or 13 years. VB was a very good choice for my Windows focused development because the dialect for VBScript, Microsoft Office Macros and ASP was all the same and every COM-component developed with VB could be reused in Scripts, Office Macros as well as ASP web applications.

So whereever there was something to develop I could do it most efficiently using VB and reusing components or single methods I already developed. I also have some little experience with "language hopping" by using a little Python here and more PHP over there.

The experience tells me that every language has its own pitfalls and while hopping from one to the other you either trap in the beginners problems like missing a semicolon here or mixing up indentation there. If you can focus on one language which can be used to do everything then you should prefer that - you are simply more efficient in programming.

The two major benefits of focusing on one language:

• Easier reusability of components and libraries you already created.
• Better knowledge of the language and the pitfalls because you have more experience on the particular language.

And that was one reason (but far not the only) I have choosen Java. And although JavaScript is not the same as Java, it has at least same basic syntax.

Related post: The programming language.

Web vs Thick client

I think their is no doubt that we are in the middle (or is it the beginning only?) of a web application hype. When I lately faced the VMWare infrastructure web access I wondered what sense that makes to intentionally reduce performance for ... - for what? For accessibility? When I am at a client where I need access to a vmware I will take it with me - on my notebook or either (as colleagues of mine do) on a USB drive. I wonder if it was a technical guy or somebody from upper management taking this decision...

So I think there is some clarity required when it makes sense to design an application as a web application and here are the advantages:

1. Zero installation at client side.
   I think this is a big advantage of a web application and and from what I have seen drives many people to design the next application as a web app. I can see it from my own experience at Windows related support. On approximately 1 of 10 workstations there are troubles installing an application due to some "corruption" at the system or some other application conflicting. But this also depends on the application. For highly integrated applications (having intensive contact with OS or other components) I expect problems at 1 of 5 machines at least. So one reason for a web app is to avoid installation problems. - That is understandable, but guys, remember: That is an OS problem in reality. I very rarely have problems with installations under Linux. So for the zero installation we are in reality talking about a workaround for a Windows problem. - But wait: There are also the dummy users who don't really know how to install and those who don't want to bother with installation...
   
   
2. No updates at client side required.
   Whenever an application is installed there are also updates needed. Installation and updating is always work needed - in most cases somehow the Administrator and/or the user is involved and somehow handicaped or interrupted in his work. Yes, this is very bothering and for the vendor it requires also to maintain the appropriate infrastructure for downloading updates and (on Windows) the appropriate feature set at the client checking for the updates. The advantage of the web application here is that every user automatically is using the most current version as soon as the server has been upgraded.
   
   
3. Platform independency.
   Also a good reason to design a web application. But there are issues with different versions and types of browsers. So dependency from OS is traded in for dependency on the browser - which anyway seems to be the better choice...
   
   
4. Accessibility.
   New users can usually get access to the application very fast - they only need to surf to the particular site and they are there. This is a very important reason to design as a web application if it is important to get the masses and those who only use the application from time to time. Nobody wants to invest additional effort for installation of a software he or she maybe uses only once and maybe the next time only in a year from now. Although - if we look at Skype for example - if a software is worth using, many people install it also locally.
   

Note: Using Java or Python for instance you could also gain platform independence without the need of using web applications.

While it sounds very good anyway to use web applications there are also disadvantages coming with this architecture - well there is no advantage without disadvantage - this people tend to forget. There are also good reasons for using thick/fat clients:

1. Performance.
   Using a thick client data transfer can concentrate on the real data. All client logic and GUI is kept on the client. So performance of thhttp://it-tactics.blogspot.com/2008/11/web-vs-thick-client.htmle net traffic is in general better and servers do only have to deal with the server business logic and storage/retrieval of the data.
   AJAX and RESTful programming is a workaround to the problem of web applications that GUI and all the program code has to be transferred when the application is used.
   
   
2. GUI Features.
   Thick clients have more freedom (access to local data) and more possibilities of GUI design (available widgets, drag and drop for instance).
   
   
3. Available Offline.
   Thick clients can be used offline (if the application itself is not requiring the connection). For example data can be saved locally and can be transferred when you are online again. Only thing: The application has to support such an offline and online use (or synchronization respectively).
   
   
4. Privacy.
   You might produce or deal with data that in a whole or in parts should not be transferred to the server. This is one reason why I think that a local office software pack can never be replaced by an online office. I think that there is no company that wants to rely just on the provider to keep the company data save and private. As an alternative the company needs to provide the appropriate server environment to provide the office functionality. Another example is CRM - I think that people prefer have their contacts locally with them.
   
   
5. Different configurations and versions.
   Using web applications all users have the same version, this has already been mentioned. What in general is an advantage, can also be a disadvantage when you want only a few users to test a new version or when different users have different requirements. Firefox is a good example here: There is a basic product and a huge amount of available plugins. There will be nobody using all the plugins and Firefox would need a startup time of one hour and then hang up. Instead every user is using those plugins that are focused on the needs of the user optimizing productivity. This can only be done when every user is free to use an adapted version of the software.
   
   
6. Distributed computing.
   Using rich clients you split computing power between server and client. Some applications are either focused on decentralized purposes - like file sharing for instance. It also can be an advantage if the application hangs - because then in more cases only the client hangs and not the complete application at the server.

There are good reasons for both types of architectures. I can say that I use both - web clients and fat clients and both make sense according to the purpose of the application. It is important to think of how you want to implement your solution. Don't take the decision to implement your program as a web application or a thick client just because of a hype or by looking at it from a religious point of view!

Related posts: Your holy machine, About agile software development, Web application security, Pros and cons of cloud solutions.

Technical side of management

When I was thinking about some next post I somehow had the impression that a decision must be taken whether I want to write more for technical focused guys or a little more for the management focused people.

The final result is that I think it is one of my specialities that I do have the technical background and knowledge but I do want to see the final purpose. For the final purpose you need overview and this is also what management needs.

Although I am trying to improve productivity by using helpful software I do also know that sometimes pen and paper is simply the better choice. I look at the actual practical need.

So this blog will continue to address both type of readers somehow and I think especially nowadays often there is a gap (or rather a canyon) between that management and the technical or practical solutions. Both often do not well understand each other and therefore often management takes decisions that cannot really be implemented in a way that still makes sense.

I will try to fill this gap a little.

Simple IT

Last Friday when I went to buy some food I saw two guys working on an old Ford Capri (like this one, although in red). It was from 1972 and one of the guys told that he is still the first owner.

We began to talk a little and the other guy - about to repair something - told that in two hours it's will be done although some bigger change. When I mentioned that with the modern cars it is not always that easy he got red, agitated and began to badmouth (I was worrying if there will fly tools in a few seconds) about the modern cars. He told that he worked on a newer car some days ago where it took two hours only to remove the parts so that he could get to the main part he wanted to change or repair.

I know it from my own experience, that in newer cars sometimes it is either very difficult to change a headlight yourself.

Well, this is an IT blog so why the hell I am writing about cars here?

The answer is simple: I think that in IT similar changes happened. While software and either programming languages get packed with a lot of features the basic purpose often suffers.

Example: Many years ago it was sufficient to copy an executable (and maybe some configuration or data files) to a destination folder. Nowadays special tools for setup creation must be used (and either programs in their particular language must be written - the program for the program) and then it is not sure that everything works fine then. And it is possible that you need additional runtimes in addition to the setup (some setups for .NET applications for instance).

And then applications often need very huge amounts of space - memory and harddisk. I had the MS Visual Studio 2005 installed which used more than 2 GB (!!!) on my harddisk.

Or to mention the libraries and technologies in Java: Spring, Hibernate and all those "frameworks" - there might be a reason to use these in very large applications or projects, but I guess in 75 % of the projects using too much of that stuff only produces bloatware without a real benefit. I have been on a course for Alfresco API and one of the major impressions was that 75 % of the time we were struggling around with XML files and only 25 % with coding.

It often seems that IT is very far from applying the KISS principle, hence I strongly recommend reminding to it. Try to keep it simple. IT is already complicated enough even if you keep it simple!

Related posts: The good, the bad and the ugly; The Features.