How to design a good about box?

Question

There is not official standard dealing with the layout of about boxes, which display the credits of a computer software and other information.

What should a good about box contain? And... is it okay to put an easter egg in?

_{(source: seasip.info)}

Answer 1

Looking at a few examples of About boxes:

• Name of the software
• Name of the publisher/author
• Copyright and licensing information
• Version information
• A nice logo

These days, it probably wouldn't hurt to have a way to directly go to the website for the software in the About box itself.

Microsoft's Windows Vista User Experience Guidelines tend to have useful information on designing good user interfaces. I wasn't able to find information specific to About boxes, but the section for Dialog Boxes may be somewhat relevant.

Answer 2

I generally prefer to make tabbed "About" boxes. The first tab usually displays information about the application (name, version, copyright, etc.). The other tab is usually a log of changes with the most recent changes at the top.

Answer 3

Legal will want their copyright and stuff, marketing will want their branding (even though the user has already bought the product), the dev team will want their names up there in liquid crystal, but what do users need?

1. App name and version number. Users may need this to troubleshoot problems, perhaps while in contact with tech support or when using a knowledge base. Use a version number system such that this is all the user needs to specify their build. Version number is also needed for the users to know if they can upgrade.

2. A brief statement of what the app does (e.g., “Photograph and picture organizer.”). Users often end up with software for which they can’t guess the purpose. “About” is a logical place to tell the user what the app is about.

Put the above in conspicuous text at the top of About. Have a single OK button. Everything else that may be required by others in your company really isn’t of any interest to the user and can all be in “fine print.”

You could also include the web site or email for tech support if you can rely on that being stable for years, but usually users have this before going to the About box.

Easter eggs are fine if you think it’s appropriate to have a little fun in your app and your users lean towards the geeky side of things. Just make sure it isn’t something that will alarm a low-end user (or a future high-end developer; see: http://blogs.msdn.com/jensenh/archive/2005/10/20/483041.aspx).

Answer 4

A team in my workplace actually has made the coolest About box ever:

Every time you open it, it displays a different simple game, with pictures of the dev. team (memory games, tic-tac-toe, sudoku, etc)

Answer 5

As for the About page content, that is the best place to have the version / release information so you can offer easy support.

I am using mine as the abstract description and a link to the legal pages and a credits page. If you have a website, its URL should be there as well -- might as well make that click-able into your own web-view browser to your big "Company About" page on your web server (don't launch a real browser, or the user just left your application).

Make it enjoyable to read but be concise. Avoid any scrolling or paging -- except to a completely different set of informational screens.

Also, let it be obvious and easy to dismiss.

By-the-way, if you add an easter egg to an app that is submitted to Apple Store, you have to disclose the sequence for Apple to 'test'; they promise to keep the sequence confidential. If they discover it later, which will make it back to them through forums, etc., then they will automatically pull it from the store.

Answer 6

I tend to add program name, version, company copyright, contact information, license information. I also add various variables for problem resolving. Winows version, servicepack, dll version if i use critical dll's etc. A large application icon. Sometimes I add an easter egg or some keycombo that launch parts of the program meant for debug and support purposes.