Managing client software can be easy when planned and administrated properly. A good deal can be achieved using Domino policies, Smart Upgrade and some silent install options when rolling out. If you want to remodel your environment (e.g. to move the data directory into to user profiles and clean things up) you could consider using the Panagenda Marvel client or the BCC Client Genie (both made in German speaking Europe).
But there are more options to consider. As you might know Notes can run off a memory stick (Lotus Nomad), technically more correct: off a removable medium. Nobody stops you from preparing an ISO image and mount that on the machine you want to use it. There are sufficient tools around to help you on the mounting process. Of course Nomad comes with a set of its own challenges. Following the idea, wouldn't it be great if there would be a virtual file system that would handle a virtual registry and reduce your whole install to a single copy of one executable file. Many years ago (in a different life) I used a tool that did exactly that. Its name was Thinstall. It was provided by a small innovative company, which was OK for my requirement then, but would have me worried for an enterprise deployment. The company is no more, since EMC/VMware realized their potential and bought them. The tool is now called VMWare ThinApp and has matured from its already promising beginnings. A client licence goes for below 50$ for the runtime, but you need the ThinApp Suite 4 to package your application. Just imagine: any app you deploy is an install free single exe file. That would be just like one of the mobile app stores.
As usual: YMMV

Archival often gets confused with backup. The activities are (technically) very similar and invite such a confusion. Both are the action of moving bits from "the place where everybody looks" (the mailbox, the current database, the file share, the intranet etc.) to some other place (a backup tape, a cheaper storage, a CD-ROM /dev/null etc).

Backup is for the sole purpose to keep data available in case the main storage area is no longer available (due to accidental deletion, soft- or hardware problems).
Archival is the removal of data from the "main area" to an "archive area" for later retrieval for historic or compliance reasons. A secondary motive for archival is to remove obsolete or less relevant data from the active work area to improve performance, shorten search time or save on storage in the system hosting the active work area. To confuse matters further: quite often technologies designed for backup are successfully used for archival (e.g. copy data to a removable storage like a tape or optical disk).

In other terms: you don't expect to ever restore a backup unless something went wrong, while accessing an archive can be part of a regular business process. There are a few perceptions about archival that need to be put into perspective:

Archival does not save any storage space!
At least not when you look at all storage across the Enterprise. However it can help saving storage on your active work area (which is most likely the most expensive one) and so help saving storage cost. IMHO the biggest advantage of archival is the reduction of data a user would look for, since the current work area only would contain relevant data. This is also the greatest peril of archival: when data gets archived too early and the archival location turns into yet-another-work-area-to-check. (OK your archive might use a better compression that your life system - but are you sure that is isn't just a backup?)

Archival needs information life cycle management
Every information has a certain life cycle. Like food items information has a "best use before" data (that varies depending on the purpose). It follows roughly the following pattern:

• New: freshly created, might not be relevant yet (e.g. upcoming policy change)
• Current: data supports one or more business processes and is actively used
• Reference: data is no longer actively use, but is regularly required for reports or comparison
• Compliance: data is obsolete but needs to be kept for compliance (e.g. business records in Singapore : 7 years)
• Historic: the data doesn't need to be kept, it doesn't serve any active business process, but might be of historic interest. This state of information is a field of tension between (corporate) lawyers and historians: historians like to keep everything, while lawyers see a potential discovery risk (cost and content) in every piece of data kept. When analyzing the archival policies of any organization one can find out who won this conflict.
• Obsolete: In 2050 really nobody cares how many rolls of toilet paper you bought at what price (while the price volume of toilet paper might still be of historic interest as curiosity how mankind could be so wasteful with resources before they had the self cleaning buttock nano coating)

Data might skip some of the phases. As one might notice I'm speaking about "data" in general. The life cycle applies not only to documents but to all sort of information. Now to have a successful archival strategy the status of information in that life cycle should be explicit known for each piece. Unfortunately this is still the exception rather the rule. Short of an explicit expiry data we make implicit assumptions like "Unless stated otherwise a document in this place expires xx days after last update" or "Unless stated otherwise a document in this place expires xx days after last use". Since usage is much harder to track (if one looks at an information to then figure out that wasn't what she was looking for, an automated system would count that as usage - bad. Or I use the search engine and the search result shows already the information, so I never open the location - document expires being unused - bad) the most prevalent measure is "last update". Some clever verification  cycle asking the owner to extend the validity is needed. But better have a clever one. If that turns into a one-bye-one update exercise nobody will bother. A very good rule engine can help there. Most of the technical troubles (short of broken equipment) you might experience with archival are rooted in strategic (mis-)decisions.

What's your Retention/Archival policy?

In Domino 8.5.1 the IBM OneUI v2.01 files were sneaked in. In Domino 8.5.2 they will be official. (I've written about IBM OneUI before). So it is time to look at the official 2.0 documentation (or the 2.1 version) and make yourself familiar with the concepts. To use the OneUI ou just manually type oneuiv2 as your theme and your application will pick it up. Make sure that you type that all small, so it works on all servers. On my last count the styles contained 287 unique .lotusXXX class names and 102 .xspXXX class names in various combinations of HTML elements and nesting orders. So somebody spend a substantial amount of time to get all the various cases covered. I probably will blog about the structure a little more in future. To make use of these classes more convenient I updated my dummy stylesheet and provide 2 stylesheets, one for .lotusXXX and one for .xspXXX to include in our projects. There are no CSS definitions inside, so you won't have unwanted side effects.

On a Notes client your email is stored in your mailbox, your contacts in your address book, typically the names.nsf. Since that file is hardly replicated back to the server (unless you roam) a different place for contacts was needed, so you can use them in Lotus iNotes or Lotus Traveler. So contact sync was born. It its latest incarnation it is a task on your replicator page, that makes sure that the contacts in your local address book are kept in sync with your mail file and can be managed and groomed by your personal assistant (if you have one). All contacts are copied into the mail file with the field $PublicAccess set to "1". So anybody who can read your calendar entries (the calendar entries, not just your free time) will be able to see your contacts as well. Typically that would be a team member or a personal assistant. However you might want to keep your addresses in your address book a little bit more personal (the public ones are on Facebook anyway), only allowing them to be seen for users who can see your eMails too.

Currently you can use the [x] Mark private check box for a contact and it will be hidden from anybody but you, the LocalDomainServers group and anybody with the role [PersonModifier] (a role that doesn't exist in normal mail files).

To keep it a little more open we need to customize our contact form a little (Remember you need to follow some guidelines when customizing IBM templates). When you inspect the Contacts form of your names.nsf (or your copy of pernames.ntf) you will find a checkbox "Confidential". It is the box that shows the [x] Mark private check box

Behind that check box you now add your one field named $PublicAccess. Make it a check box too. Give it a value of Hide from calendar users|1. You might look for a clearer wording here.

In the input translation formula you add a little @Formula magic to make it work with the confidential field: @if(Confidential="1";"";@ThisValue). With the check box set (which won't stay if if is confidential) only user who can read your emails will see the addresses, but not those who only can see ones calendar.

As usual - YMMV.

We get exited about new software releases. Full of enthusiasm we swarm out to tell the world of business users about all the shiny new features. We are met with a shrug. What went wrong? We used the wrong approach! We drowned our audience in the river of features. When presenting new software to business users, be it a new product or an upgrade to an existing software, listing features (how kewl is that...) won't excite anybody outside tech. We need to tell a compelling story how the new software improves the utility of users' computer use. In other word we need to clarify what's in for them.
So you structure your presentation around business scenarios and how the set of abilities in your software benefit this scenario. Software designers (at least the enlightened ones) use Personas for their scenarios. You standing in front of an audience you (should) know, of course pick examples that are relevant to the people that look you in the eye in that very presentation. However a good business scenario is not good enough. They way you communicate it is essential. Anybody loves a good story.
The best advice for structuring your presentation I found so far is provided by LeeAundra Keany a.k.a. The Contrary Public Speaker. She strongly suggest to use a classic speech approach as used by Aristotle, Plato, Quintillian or Cicero. Her presentation model consist of six simple elements (summary and explanation partly from the book, partly by me):

1. The Message
   You need to answer the question: "What do I want the audience to do and why should they do it". For software demonstrations the "What" seems simple: "buy my product" or "demand the upgrade", but after a little soul searching you might end up with "See a different work style", "change their attitude towards ..". The why is trickier. Here you need to know your audience well - it's the What's in for me? question. A good message is clear, focused and compelling
2. Audience Analysis
   LeeAundra sums it up: "The quality of the speech itself is powerless against the preconceived notions of the listeners UNLESS the speech and the speaker understand and deal with them". So be clear who is your audience. The CEO pitch differs from the CIO pitch and differs from the message for the personal assistants. You need to be clear about three questions: "What do they think of your message? What do they think of you? What is their state of mind?"
3. The Speech
   Good speeches are short to the point. Good demos too. Your biggest mistake is to walk through endless variations of the same. Prepare the variations if our audience demands more, but keep your plan to the essentials. Write down your speech. Use simple words (keep in mind: simple doesn't mean simplistic!). Good speeches are highly structured and so should be your demo. Never just jump in, explain what will happen beforehand. I call that the "dentist model". (S)he will first tell you "I will hurt a little" before yanking out your teeth. The structure consists of 5 main components:
   1. Introduction: You provide an attention getter (no joke please unless you are really funny), explain why this is important - plan that message well, you will tie back to it - and the preview what you will show and tell in the body. For a detailed discussion of attention getter options see the book.
   2. The Body: The main part of your speech. Every item (don't have too many of them) has a point - a business case so to speak. You state your argument and then provide supporting evidence. In a software demo that's the part where you click around. You sum up the learning points and provide the transition to your next point. Build your points around utility rather than feature by feature. I experienced repeating features deliberately in different combinations for different use cases works very well.
   3. Preliminary Conclusion: You sum up the arguments you build during the main body. Don't stop like "That's what I wanted to show". You can and should tie back to your introduction. Something like "I promised to show you .... and I have delivered by ....". You also can state what else is possible that you didn't cover. Lead up to the Q&A session
   4. Question and Answer session: Of course you know your software, so any questions about functionality should come easy. However you need to be prepared for question around statistical evidence, reference customers implementation needs etc. Quite popular are questions how your product compares in function or market share to your competitors. I typically turn questions "what's about feature X" into "How do you solve the use case where product Y is using feature X with my product"
   5. Final Conclusion: Don't end your presentation with the last question from the Q&A session. Tie back to your message from the introduction. Rule the floor.
   This is a *very* compressed summary. Go read the book.
4. Delivery
   You need to practise. Practise. Practise. In IT we are tentatively guilty to use to much insider lingo, so watch out for that (and watch your use of TLA). Also slow down. Speaking faster you risk loosing your audience. Pause to let key points sink in. Silence is not dangerous. Watch your non-verbal delivery: posture, gestures and eye contact. My own posture greatly improved after practicing Tai Chi and Martial arts. Stand straight, feel both feet on the ground, be in the moment. Look at your audience. Eye contact is king. This is another reason why you want to explain things before you click through them. While you click everybody's eyes are elsewhere. And - your are not a caged animal: Don't pace.
5. Visual Aids
   LeeAundra states: "The Madness Has to Stop!" I second her. Go look at Presentation ZEN (or buy the book) Nuff said.
6. Question and Answers
   This most likely is the most important part of your speech. You switch from story telling to conversation, from showing to interacting. In the Q&A session you will reveal how well you understand your topic (and the audience), where your passion lies. A good answer to a question accomplishes three things: it answers the question, it strengthens your argument and it reaffirms your message.

LeeAundra has a Podcast and sells her book online. Go it's one of the best career investments you can make. I love the final sentence in her book:

" Now go out there and impress everybody!"

As IT professionals we are always on the search for speed. Three experts whom I respect deeply were praising the advantages of SSD drives: John David Head, Scott Hanselman and Joel Spolsky. Since Scott mentioned the good experience with OCZ drives and his Lenovo laptop and Anandtech was in favour of them too, I got myself a SSD drive from OCZ Technologies. As it turns out it has a problem with Lenovo laptops and the harddisk password. It had been reported in their forum (which I failed to check beforehand - my bad). So I opened a trouble ticket. Teething problems between hardware components are not exactly new. Here is how the saga unfolded so far. The OCZ ticketing system doesn't allow the customer to see the history, only add new comments, so my replies might not been fully accurate until #5, when I started to keep copies:

1. Me: Open a ticket in the online help system and ask for a fix for the error happing when you activate the harddisk password on a Lenovo Laptop that has been fitted with an OCZ SSD drive.
   OCZ replies:
   

   Your Trouble Ticket has been submitted with the following information:
   -------------------------------------------------------
   Trouble Ticket ID: [ID]
   User: Stephan Wissel
   Date and Time Submitted: 05-10-2010 @ 01:23:17AM
   Trouble Type: Flash Drives
   Trouble Priority: Technical Support
   -------------------------------------------------------
   Short Description: Vertex 128GB - [SERIAL]
   -------------------------------------------------------
   Please save this email for your records
   
   Regards,
   ocztechnology@exdesk.com
   
   

Every CIO's office is challenged with the amount of computing freedom it should allow its corporate users. Thus the spectrum reaches from Stalinist: " We tell you what bios version and revision your hardware has and what tie you have to wear before you can login" to Peacenik " Everything is connected, the universe will guide you in the selection of hard- and software". As we all no extremes usually don't yield the best results and we should stay on the Middle Path. I like the approach IBM is taking here, which I would encourage to copy. IBM has clear guidelines about workstation security. Any device connecting to IBM's internal network or processing IBM data must comply. We have tools that check compliance and help users to adjust if there are problems and to escalate them if they don't get fixed. The CIO's office maintains a list of approved software. This software comes in three flavors: software that is part of our standard image, software that can be installed when needed and comes with full support (you can call the help desk and open a trouble ticket) and software provided as-is (no trouble ticket, but discussion forums and user self help). Installation is provided from an integrated tool in IBM's w3 intranet. You pick your software from the list and the rest is fully automated. After going through a briefing we also can use OpenSource software as we deem fit (within the margins set in that briefing).
The CIO's office doesn't prescribe the hardware. You can use you own computer - what an increasing number of IBMers do when switching to a Mac. Of course most IBMers will use a Thinkpad that is provided in a set of standard variations (X series, T series or W series).
After all IBM is a technology company, so how do we handle all the latest and greatest software? Since the CIO needs to provide full support for official software and upgrading a 400k strong workforce isn't done in an afternoon, something bridging that gap was needed. So about five years ago IBM created the Technology Adoption Program. In the TAP program IBM's own latest and greatest software is available. But it is not only software you find (or will find) in IBM's price list, but innovations that have been created for internal use. As a matter of fact a huge number of TAP innovations are created by IBMers not working in software development. TAP allows everybody to contribute, try and vote. Successful tools graduate one day from TAP to the CIO's official supported list. While you find software from all IBM software brands here, I mostly pay attention to Lotus stuff. We have heaps of plug-ins, a modified mail template, Notes 8.5.2, SUT etc.
One can also find the IBM Open Client here. For Linux users we have 3 levels. IBM maintains their own internal software sources and we have stable, beta and experimental. So based on one's taste for novelty vs. security any of the three can be picked (Easy to guess which one I picked). Using a TAP approach has a clear set of advantages:

• The CIO's office can evaluate software on a broader basis
• Users with low risk tolerance can stay with well established fully internally supported software
• User who like new stuff can be provided with the latest and greatest without having to make an enterprise wide commitment
• Innovation can be fostered. With TAP in place any piece of software becomes visible to the enterprise at large. Also internal contributions (e.g. we have corporate templates on TAP) can easily be shared.
• Better control: TAP allows a liberal look-down: You want to use this or that? No problem, we put it on tap. No other stuff please.

Of course funding and acquisition of licences need to be handled by TAP, but that's a different story for another time. If you ask nicely IBM will help you to adopt your own TAP. As usual: YMMV.

I'm a week late to the party. Every time I tried downloading from a server in AP I got 5-20kb/s download speed. And I'm hardly long enough in one place to wait that long. Enter Bittorrent and its default Ubuntu client Transmission

1 MB/s is the stated maximum of my broadband plan.
Nota bene: This is a perfect example how Bittorrent is used for effective and efficent distribution of fully legal content.

I love the cloud. It provides access to all my data from any device, any time from anywhere (and for anybody when the next security hole is discovered). No headaches about backup, storage and undelete. I'm on cloud 9.
Not so fast. When I need the service most it is down, the network is slow or latency is unbearable large. The cloud turns toxic. But I want my cake and eat it too. And yes it is possible. The secret is called sync (others call it cache mode). I only mostly want to interact with local apps and local data. These local apps send and receive data from the cloud as and when they have connectivity. They do that in the background, they don't bother me. The apps update themselves from the cloud if I permit it (individually or blanket permission). The apps are smart enough to figure out what data can be kept local based on context and device. To achieve that synchronization is king. There is still dust over the sync protocol battle. We have SyncML, CouchSync, NRPC, HTML5 sync, .net Sync, Expeditor sync and many others. Partial sync (what I would call " contentual sync) hasn't been solved satisfactory. What is your sync strategy?

Teaching complex topics is as much an art as it is a craft. To become an artist you have to be an artisan first. One of the tools of the trade are clear structures in your teaching materials. While working with Digicomp I was introduced to TeachART that anwers the question for adult education. Based on that knowledge and my 2 decades of training experience I found the following structure to work well for study assignements.

1. Learning Goal
   Introduce the exercise and what you will learn. E.g. "In chapter 7 of 'Cullinary survival for geeks' we will learn how to prepare Spaghetti al olio."
2. Learning Rationale and Time
   Explain why one wants to learn this specific skill E.g. "The dish is rapidly prepared providing advanced carbs for mental activity without distracting too much from other work. The light oil coating makes them tastier and plesant to eat."
   How much time should this exercise take. "Allow 25-30 minutes for this exercise. While the noodles cook (about 20-25min) you can chat with your classmates"
3. Prerequisites
   What do you need to know to succesfully follow and complete this exercise. E.g. "Before attempting this exercise you should have successfully completed chapter 3 'Boiling Noodles'". Sometimes you can condense the prerequisites into a short statement: "All exercises are designed to be completed in sequence, the results are the prerequisites of following exercises". Of course you need to formulate the prerequisites for the whole class clearly: "You are a geek who is fed up with ready processed food and like to try something new. You can handle a kitchen knife without major injuries to yourself and others. You are willing to eat your own cooking - if we are successful."
4. Success control
   Tell how the succesful outcome will look like, so students can gauge for themselfs how successful they were. This is very important. Try to give as much indicators as possible for a self assessment. For software screenshots are a good approach. Don't describe what to do (that's the next step) but the outcome and how to verify its success: "Your noodles will have a bite that is soft at the outside with a little firm core. You can see a gloss on the noodles from the olive oil but no puddle of oil below the noodles. See this picture..."
5. Detailed Steps
   The "meat" of the chapter with steps to follow. Design them matching the audience. If you describe the steps in too much detail they become boring, if you are too brief students get lost. If an exercise includes steps done before, refer back to them. "Prepare noodles like in chapter 4. Use frying pan #3 to heat 80ml of oil. Use heat #2 on your oven ...."
6. Food for thoughts / Things to explore
   What else could be done. What are variations of the task. This is an important buffer for your fast students. If they finish ahead of time they can deepen their understanding with additional exercises. "You can cut one clove of garlic before heating the oil and mix that into the oil when it is hot."
7. Related information
   Where can the students find more information. Like variations of that exercise, background information or alternative approaches. "In our cookbook page 321ff you will find more spaghetti variations: spaghetti al pesto, spaghetti carbonara or spaghetti al pomodoro. A discussion on carbohydrates as brain food is on the course website together with tips how to pick the right oil for your taste"
8. What's next
   Again you could shortcut that by the implicit sequence of exercises or you suggest a learning path. "The Spaghetti have boosted your brain functions, so you have completed your work assignement ahead of time, so you will learn how to reward yourself with a nice dessert in chapter 8: 'Pull me up - Tira mi su'"

So it is: what, why, how. Creating good materials is hard, time consuming work and as usual YMMV.

Open Source is something different from Open Standards. We like to confuse the two. An Open Standard can be implemented in 100% proprietary software while Open Source software can implement proprietary standards (is that an Oxymoron? - prevaling practice might be a better word here). One example is Gnome Evolution implementing the proprietary Exchange wire protocols.
Hugo Roy, in an open letter to Steve Jobs sums up Open Standards for the busy reader:
An Open Standard refers to a format or protocol that is

1. subject to full public assessment and use without constraints in a manner equally available to all parties;
2. without any components or extensions that have dependencies on formats or protocols that do not meet the definition of an Open Standard themselves;
3. free from legal or technical clauses that limit its utilisation by any party or in any business model;
4. managed and further developed independently of any single vendor in a process open to the equal participation of competitors and third parties;
5. available in multiple complete implementations by competing vendors, or as a complete implementation equally available to all parties.

Steve disagrees citing " An open standard is different from being royalty free or open source". While the later part is almost without discussion (some claim a standard can't be truely open if not at least one Open Source Implementation exists, thus the standard being like a class and the source being the object instance of the class), the former is hotly debated. In one camp the term " without constraints" is interpreted as " patent and royalty free" while the other camp ( including IETF, ISO, IEC, and ITU-T) wants to allow for " reasonable and non-discriminatory" patent licence fees ( RAND). The FSF would see RAND rather as a short form of RAN(D)som. We live in interesting times.