Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts

2012-04-15

New user experience

Yesterday I made an experiment which for me is difficult to do: I showed Ubuntu 12.04 to a person (about 70 years old) completely new to computers (only used the mouse to click through a set of photos so far but that's it). I only know a very few people of this type (most already have used computers).

I have seen a lot of funny and interesting behaviour (like hit the key with the pipe character written on it instead of i ;-) - never thought of things like this). Don't want to go into detail - just share the most relevant results in very short:

  1. Big icons are not only for people visually handicapped - also for people who are not familiar with a mouse (or relevant for touchscreens: have big fingers). A quadratic form is easier to click than a rectangular shape (text on websites is rectangular shape and more difficult to click than the Ubuntu Unity launchers for example).
     
  2. Without explanations - whatever Operating System - a complete newbie person cannot learn only on his/her own. There needs to be a person that explains. Not to talk about administration. A newbie with low experience level will never administrate the computer on his/her own. There must be a person with higher experience level helping out and doing this for everyone who just wants to do a few things (or must do). This draws a very important conclusion for me - confirming my belly feeling somehow: The operating system must try to minimize the annoyance for that guy behind everything. The person that needs to help out the core family and a dozen of friends! - That usually are IT people or at least the very technical interested guy/girl. So companies or communities building an operating system need to focus more on the technical person than on the new user! If the guy/girl that needs to administrate, hates the OS he/she will install something else and the user needs to adapt. For the unexercised user efficiency differences of one or the other operating system are irrelevant - not so for the power user or IT guy! So those driving an operating system forward with their experience and with their desires for improving efficiency are the key group - they are the experts others will trust. Who would you rather ask which new car to buy - the flower lady at the corner or the taxi driver?
     
  3. Most websites are far more complicated to use than the base operating system. Navigating those sites is far more hassle. Last but not least because they do not tend to look similar. Imagine, all websites would have a standardized menu so that whataver company site you are at, you find the link to the office hours at the same position.
Related post:  The truth about software.

2011-10-27

The individual desktop

I can see an interesting movement on the market: Many Apple iPhone users seem to lurk towards a Mac when they think of buying a new computer. - And some actually do.

And in my neighbourhood I can count already 6 Macs in the first minute trying to count them.

I find it a good thing, that Macs are increasing. With more people using Macs, companies need to start considering that there is not only Windows and world is colorful.

There is just one thing that I need to make clear: Many Mac users think that they are a special individual with their extraordinary computer and this is not true IMHO.

I can see the following different strategies:
  • Microsoft: Keep compatibility to keep market share but try to offer new GUI stuff that feeds people's enthusiasm and keep some flexibility.
  • Apple: Focus on usability and don't make the user think or choose.
  • Linux: Be open and flexible. Everybody should be able to use it as desired.
I was thinking if there could be the optimal all-use-fitting user interface but I came to the conclusion that there are many different use cases, many different jobs and many people thinking in many different ways.

I think, the Apple way is not the worst, but for those who work a lot with the computer it might be worth to invest a little more time finding the best fitting environment. If you want to be really individual, Linux is the way to go - just search youtube - e.g. for "my Linux desktop" or "top linux distros" to get an idea what people do with Linux.

Related posts: Distribution choice, Popular Ubuntu desktop myths.

2010-08-24

Pros and cons of cloud solutions

Whenever a new (IT) hype is getting attention, I am careful with jumping on the train. Often it is just old stuff in new clothes and often big disadvantages are involved doing things in a completely new way. What also always happens in such a hype case is that first definitions are refined and cleared up, but later on everybody claims to offer products that match the hype (yes, when DMS (Document Management Systems) were the hype, printer manufacturers claimed doing DMS - and they were somehow right ;-) ). For a description of what "the cloud" is, look up "Cloud computing" at Wikipedia.

I am using "cloud" solutions (or let's say web applications offered by external service providers) myself. I tested and tried many, when they are still free but nowadays the providers start to charge for those. I still use several Google services (Google search, GMail, Google Calender, Google Reader and Blogger of course), mite (not free any more for new users), Vyew (occasionally) and some social networking sites (XING, Facebook, LinkedIn). I have dumped many others because of several reasons.

The pros of cloud based solutions:
  1. The application and data is available from everywhere (every machine you are using).
    Well, if you have a home network plus fix IP address (or using DynDNS or similar service), but:
  2. You don't need to do maintenance work (apply security updates, ensure power-supply, repair broken hardware etc).
    OK, you can rent a server (space) somewhere with different levels of maintenance work to be done by you.
  3. The applications scale well (usually those services run on infrastructure that allows scaling).
    OK, if only you are using the application (and maybe some family members and friends) you might not need any scaling, but if you are a company (maybe a startup that expects or hopes for fast growing) this might be a real advantage.
  4. Costs
    If you or your company is quite big and/or using a lot of software there might be several servers required and maintaining a smaller or larger server farm can be costly (just think of ensuring power supply and keeping spare parts of used hardware pieces like hard disks and so on). Cloud service providers are specialized on providing computing power and with the mass they can do it cheaper. I think this is the real driver for the rise of cloud based solutions (what a finding, that most things are driven by money...). Especially when you have only peek times where increased computing power is needed (e.g. some batch jobs running at night), it might be costly to have many servers up-and-running doing nothing most of the time.

The cons of cloud based solutions:
  1. Privacy
    You do not know what the service provider is doing with your data. At best I would think they are only running some statistics to see where you make your business, what are customers buying from you (in the meaning of what products and services are going best) and so on. I think that depending on the service you are using there are usually some interesting statistics to be made that could be sold for money to consulting companies. If the service provider is not trustworthy, I could even imagine that they could sell more detailed data.
  2. Influence
    This disadvantage does not (fully) apply if you are using services like Google app engine or EC2 because there you have more influence on what you are running (more or less your application or entire virtual machine that is just running on their hardware). Using an in-house solution you usually have more influence on the system configuration and the software, you are using. I have instances of phpBB, Wordpress, vTiger and others running. You can apply plugins as you like and have access to the source code (to apply fixes or some really personal adaptions). You can make backups and snapshots as you like, directly manipulate the database and so on. And you can pay developers for implementing your own requirements - which can be very important because how do you expect offering outstanding services, if you just use what everybody else is using? Using a service provider, your possible influence is usually very limited and you have the same functionality that everybody else has, who is using the service.
  3. Security
    This disadvantage again does not (fully) apply if you are using services like Google app engine or EC2. But within an externally hosted application you are often sharing resources or the whole the application with other users. Who does guarantee you, that there is no security issue that allows one user to see private data from another? This is an additional security issue category apart from those regarding security hacking from outside.
  4. Dependency
    You can only hope that the price of the service is kept at a reasonable level and that the provider company is not going bankrupt or somehow else stopping the service (even big companies are closing down services from time to time because they do not make enough money with them).
  5. Performance
    Why performance? You can get a lot of performance by just renting more computing power? - The truth is: The performance increase you can get is for external users of your services. Remember, that with the solution in the cloud also the relevant data also needs to be there (or at least transferred back and forth more often) - and for you the data is then far away (internet is very slow in comparison with local access). Or if you host just the data inhouse, you anyway may get a performance issue (this time the access from outside if you don't have a fast database running on fast and enough hardware).
    For example: We have outsourced our FTP server for software installation package downloads and now putting a new version online takes a lot longer than before.
    Apart from the network traffic, even my laptop is already a dual core (bought more than a year ago), friends already have quad-core laptops. And using web applications in the cloud, there is nearly nothing to do with that enormous computing power (with just the browser running to surf the internet).
    In many cases it is definitely more efficient to run the applications local and just send the data over the (inter)net where necessary. Implementing a web-application that offers - let's say Word/Excel/Powerpoint-like features, require much server power although that computing power is already available locally. And I can see already a tendency back from web applications to full clients. But this begins to get off-topic because this is rather a thick vs thin client comparison - we had that already. - Final word to the performance: If you really need much computing power, then the cloud can really help you.
Final words: For big SAAS (Software As A Service) providers cloud based solutions are THE way to go to fit variable usage, costs and scalability. BTW: In theory a big company could also maintain an own server-farm for use and sell computing power in a cloud-like fashion. For a small startup the cloud is attractive because you can get going without investing too much in your own IT environment. Although, when you use a little more services than just Salesforce for example then several services can sum up in costs and lack of integration between each other. For a lot of mid-sized companies I do not see that relevance of cloud based solutions. And last but not least: Plenty of companies see their business contacts and business data as crucial for their success so they want to keep it very private (or they might be even legally bound to keep things private) - or they simply want to be flexible and reduce dependencies or vendor lockin respectively.

Last but not least: Implementing a solution in a cloud-enabled way requires additional considerations and work due to the problems coming along with computing in the cloud, so developing an application enabled for the cloud is usually more expensive (although depending on what exactly you are going to transfer to the cloud - that is not necessarily always a whole application, it can be a single task/job also).

Related posts: Web vs Thick client, Your holy machine, Surveillance, privacy (NSA, PRISM, ...) and encryption.

    2008-11-26

    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.

    2008-11-18

    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.

    2008-11-09

    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.

    2008-10-06

    The framework

    If somebody would ask me for a contribution to the buzzword bingo game then my 50 cents would be the word "framework".

    Companies are building huge frameworks - even big pieces of software - stating that it does provide a framework that enables you to do everything and the workflows, the meta-information and all the rest only has to be configured or implemented.

    Well folks, they sell you everything and nothing. Often they even give away their framework for free. What they sell you then is consulting, configuration and implementation.

    A piece of software being "only" a framework can make application development easier but a framework without some concrete implementation is worth less than an application (that is maybe less flexible) but actually doing something that is saving you work or opening opportunities you didn't have before.

    Nowadays companies do have to maintain several different pieces of software and each new piece introduced has to be flexible so that it can fit in. However, the flexibility can be exaggerated to a level where pieces of software are written that - in theory - could help you to achieve everything, "it just has to be implemented". That makes real sense...

    From the technical point of view there is another issue arising with the hype of frameworks when they are stapled together. A larger application can make use of several frameworks and libraries for object serialization, javascript operations (AJAX), database abstraction and many more. For smaller applications making use of many frameworks you get a big bulk of overhead.