Let us know why and help us focus on your needs.

Power Manager 3.7.1 provides an easy way for you get in touch and tell us what we could do to better.

Remove Power Manager comments screen

Power Manager’s new removal assistant includes a screen for sending us comments and suggestions. You can also request to be e-mailed when new versions of Power Manager are released — maybe the next version will entice you into joining us.

The removal assistant lets you send us the following:

• Your comments and suggestions;
• Name and e-mail address.

If you decide to get in touch, the following information is included with your feedback:

• Power Manager version i.e. 3.7.1;
• Identifier of the removal tool used i.e. uk.co.dssw.powermanager.remove.

You can choose not to send us any feedback by unchecking both the check boxes. Nothing will be sent and no contact will be made with DssW if both these boxes are unchecked.

Nothing is sent if both check boxes are unchecked

If you do send us comments, feedback, or suggestions, please consider including your name and e-mail details. We read everything you send and, were possible, we will contact those we think we can help.

A few moments ago we launched Power Manager 3.7.1. This update includes a serious bug fix and a couple of minor improvements. It is available to buy and download immediately.

Power Manager 3.7.1

Power Manager 3.7.1 is free for existing users of Power Manager 3 and highly recommended.

Changes in Power Manager 3.7.1

• Improved syslog logging support.
• Improved removal experience.
• Fixed a rare bug in daily trigger calculation.

In Power Manager 3.5 we made a design mistake that made deploying Power Manager over a large network more work than it needed to be. In Power Manager 3.7 we fixed that design mistake.

Power Manager needs to store a copy of the schedule to disk. This allows Power Manager to run seamlessly between start up and shut down events.

The disk-based copy of the schedule is important and messing around with it is a bad thing. Making changes to the disk-based schedule without going through Power Manager will not end well — your changes will be overwritten if Power Manager is running when the changes are made.

Rocks at Manly beach, Sydney, Australia

The good news, for those wanting to play, is that Power Manager provides six supported ways of manipulating your schedule:

• a System Preference panel;
• Quick Schedule;
• a status menu bar;
• AppleScript;
• Automator actions;
• a command line tool.

With that in mind, we made a mistake with where we stored Power Manager 3.5’s copy of the schedule. We placed it in the hidden root user’s preferences folder.

/var/root/Library/Preferences/

In all fairness this seemed sensible. Power Manager runs as a root daemon and storing preferences along with the root user made sense. Doing this ensured the disk schedule was locked away tight from the curious. We neatly avoided a few problems that triggered our initial redesign, and we limited the scope of technical support queries arising from users who had tweaked preference file contents.

The design mistake was simple. We did not follow expected Mac OS X behaviour. Administrators expect preferences to be stored in a central location on each Mac.

Network, computer, and user preferences all have specific folders provided by Apple. By not storing preferences in the specific folder we immediately made ourselves a special case for administrators to deal with.

That meant administrators’ scripts and support tools had to deal specifically with our preference file. That hurt.

Power Manager 3.7 fixes the design mistake. Power Manager now stores all of its preferences in the expected folder.

/Library/Preferences/uk.co.dssw.powermanager.daemon.plist

I am sorry it took so long to correct. Thank you to the administrators who stepped forward to question, puzzle, and prod us back onto the right path.

Good documentation matters. What makes documentation good is partly a subjective decision. The remaining part is anything but subjective.

For Power Manager 3.7 the release notes mention that the documentation was improved. What that improvement means is the topic of this blog post.

Perspective matters

Writing documentation for software is tough. As a developer, I view Power Manager through very different eyes than you, a user of Power Manager. I see obvious decisions backed by knowledge of internal details, unrevealed from your perspective. I see an expected workflow for you that may or may not gel with your real workflow.

Queen Victoria Building, Sydney

Experience has taught me that documentation is essential only where it sheds light on a product. This might sound obvious, but the obvious is a good place to start with documentation.

Avoid wasted hours

Too often I have wasted hours of my life trying to get work done and struggling despite following the manual; unlike that stereotypical male, I am happy to turn to the manual before starting a new task or application. Those wasted hours have often ended with the realisation that the manual is inaccurate or plain wrong. Providing documentation that is wrong is worse than providing no documentation, and providing incorrect documentation is not uncommon in today’s rush to market.

Following incorrect documentation leads you down the wrong path. In the end, you are either stranded far from your goal, with many hours of struggling ahead, or left believing the tool you have chosen just does not work. Either way, the tool has failed you.

It would have been better to not see the incorrect manual and instead have felt your way forward through trial and error. A correct manual gets you to your goal faster, but an incorrect manual risks preventing you from ever reaching your goal.

Looking in the wrong direction

Why does the wrong documentation get shipped? Why does documentation not get checked and updated as a normal part of a product’s incremental development?

Writing good documentation is hard for many software companies. We tend to be focused too much on the technology and its implementation, and not enough on you and your experience.

Chinatown entrance, Sydney

Lessons learned

When we shipped Power Manager 3.5 last January, we introduced a new workflow for creating the product’s documentation. With Power Manager 3.7, this workflow was restructured and refined using the lessons learned during the last year.

Our documentation is written in plain text using a couple of different mark-up notations to apply semantic information. Semantic information is a formal way of saying that some piece of text is a title, where another piece of text is a paragraph. The art of keeping the mark-up to a minimum is the key to a good notation.

I am happy to claim that we took our notation from a well-tested source. Wiki notation is very simple, well defined, and limited.

I have David Vincent to thank for opening my eyes to the beauty of the wiki. I worked with Dave at Toshiba and he taught me a great deal about many of the finer points of being a great software engineer.

Avoid font choice procrastination

The wiki notation constrains the writer to writing. It is difficult to do anything more than write content within a wiki. The notation does not allow for procrastination over presentation, visual tricks, or hours choosing a font.

The wiki notation forces you to think only in terms of useful content and structure. Choices are reduced to how best to structure a document, topic, or paragraph. Putting the focus on the content helps create documentation that is clearer and easier to follow.

Always improving

Power Manager 3.7 is the first DssW product to use the updated documentation workflow. The look and feel of the resulting documentation has been tweaked here and there to improve readability - particularly where the documentation includes AppleScript or shell script fragments. I hope our improved documentation will help you find your way when exploring Power Manager 3.7’s more advanced features.