Compress content is a nice example of an application builded from a technical perspective instead of a user perspective.

This weekend I encountered a nice example of my previous blog: The difference between solutions from a technical perspective and from a user perspective.

I started the laptop of my father. It took 20 minutes to start. He told me that this was happen since a while. He had no idea what had happend. Every morning he started his laptop before he took a shower. After the shower his laptop was 'ready' to logon. I thought he had a virus or something like that. After a while, looking why it tooks so long to start, I found the root cause.

Compressed files in the Windows and Program Files directory.

All files which are needed to load the operating system and to start his applications where compressed. After decompressing these files, the PC started within 3 minutes. Still long but much better as it was. I can't wait for Windows 7 to start really fast.

How did it happen?
In the past the C: drive was almost out if diskspace, however his D drive was empty. (50 Gb available). The operating system had suggested to compress data. From a technical perspective this is correct. You need diskspace. However, a suggestion to move data from the C: drive to the D: drive would be much better. If data should be compressed on the C: drive the application should only compress user data instead of operating system files or program files.

Conclusion: Compress data can be useful but should not be used on all files on the disk. With a little bit more logic in the application a user friendly compress application can be made which will add value for a user. You can't expect from a user that he knows what the impact is of compressing operation system of program files.