Lotusphere 2008 - Day 4: Wednesday, January 23rd

Blogging Best Practices

Jess Stratton

This was a BOF, my first of the week, and at 7:00 AM. The agenda was loosely organized around three subjects

1. Building your brand

• Find your voice - decide what you want to talk about. Is your blog for building a business, communicating with friends, or sharing recipes? How much personal information do you want to add to it? Also be aware that everything you post -- even if you delete it later -- is still around on the Internet somewhere.
  
  The overall consensus was that you should add at least a little personal material to your blog. People can only read so much LotusScript code or NSD problem resolution techniques before their eyes glaze over. Engage the reader by making your blog at least a little personal. And never say anything on your blog that you wouldn't say to someone in person.
  
  
• Use proper grammar, punctuation, capitalization and spelling. If you write like an idiot people will assume you're an idiot. If you need help with these areas compose your blog entry in a word processor first and copy it into your blog.
  
  
• Break up content so it's not a sea of sameness. For example, in this entry I'm using headers, numbered lists, bullets and whitespace to provide some contrast and draw you to the next section.
  
  
• "Like a woman's skirt, blog entries should be long enough to cover everything, but short enough to keep it interesting." Some entries will necessarily be longer than others, but try
  to be as concise as possible.

2. Blogging policies - personal and corporate

• Decide where your boundaries are and stick to them. If you decide you are not going to post anything about your personal life, then don't do it... ever. Likewise, if you decide to always take the high road in online conflicts (and there will be some), then do it always.
  
  
• For corporate blogging it matters whether you're blogging as the voice of your company or as your own voice within the company. If you already blog and want to host your blog at work make sure your blogging is acceptable to your company before you accept the position. If you are blogging personally and do not have your company's permission to publicly state where you work, don't.
  

3. Keep them coming back

• Self-deprecating humor is appreciated. You probably shouldn't make fun of others in your blog, but making fun of yourself shows your humanity.
• Participate in the community to build interest. Comment on other blogs as a way of getting your name out there as someone who is willing to put some effort into the community.
• If possible, provide translations in other languages. There are several ways to do this, from posting twice (or more) to having a button on each post to go to an online translation service. More and more blog readers are from non-English-speaking backgrounds, and you don't want to exclude them from your content.
• Use approachable language that is clear and concise. Not everyone knows what "verisimilitude" or "adventitious" means. Awkward grammar and uncommon vocabulary is also difficult to run through an automatic translator.

Domino Designer

Maureen Leland
Mark Jourdain

In 8.01 they're adding page access control and Property Broker usability enhancements. The big news is Domino 8.5. A bit of bad news for the Linux/Mac people: Designer will not available on those platforms in 8.5, but will come afterwards.

The primary focus of 8.5 is to improve the web development experience. They're doing this by putting Domino Designer into Eclipse. When you add a NSF to Eclipse it creates an Eclipse project. There was a bunch of mumbo jumbo about Eclipse stuff and perspectives. My takeaway was you can use Domino Designer alongside other bits of Eclipse.

Bookmarks are GONE, replaced with the concept of Working Sets. A left navigator will list recent databases, or the databases in your current working set. You can create as many working sets as you like.

The infobox has been separated into a panel at the bottom, and they're trying to get everything ported over. One cool new feature: Access information. Per design element. You can see not only the last time a design element was modified, but when it was created or last accessed. The design element properties that you get from the list of design elements has also been moved into a panel at the bottom. All these property panels can be docked, undocked, floated and... resized!

There are brand new LotusScript, JavaScript and CSS editors. The LS and JS editors both include full class and function browsers, and you can use @Formulas from JS! However, the LS and JS editors are only for "full screen editors", meaning agents and script libraries. You'll have to suffer with the same old insane split-screen editor in forms, views, pages, etc. File resources will now let you include templates for XML and HTML. I'm not sure exactly what that means.

Dojo is being integrated into the Domino server, and you can use Dojo JavaScript widgets very easily. (My notes are fuzzy on the exact steps.) There are also Dojo controls for views, action bars and outlines.

There are five new design elements:

• XPages
  More on this in its own post, probably next week.
  
  
• Custom controls
  This is like a subform on steroids. You add all your controls that you want to put in multiple places and then you can drag it onto any XPage. The awesome part is you can add custom properties, such as an Edit field with data binding computed from its parent.
  
  
• Server JavaScript
  You can select whether you want JavaScript to run on the client or on the server. I don't do web dev yet so I'm not sure why this is a big deal, but it excited a lot of people.
  
  
• Domino Connections
  Create a connection to a Domino database and reuse it in your @Formulas or JavaScript without having to compute it everywhere.
  
  
• iWidgets
  Wrap an XPage and present it in Mashups. I didn't go to any of the Mashups sessions so I have no idea what this really means.

FUTURE ADDITIONS AND ENHANCEMENTS

• LS Debugger
• Formula editor
• Formula debugger
• Form/View script editors

Worst Practices

Paul Mooney
Bill Buchan

I made my Lotusphere stage debut! I was sitting in the third row and the next thing I know someone asks if I have a nice camera, I say yes, and then I'm asked to come up on stage. I recorded the opening oath that Paul and Bill made the audience take.

The session itself was pretty freaking hilarious. Some of the bits I had seen before, such as the guy who created an agent to update every document in a database, left the agent set to run on -All Servers-, then manually replicated the database with every server. The end result was 4.8 million documents being created per hour through replication.

The best part was the last bit, though. Duffbert came up on stage and gave Paul and Bill a bit of their own medicine. Apparently they didn't follow their own best practices while preparing for a certain conference. The pictures are pretty self-explanatory.















Duffbert: Change control processes?
Bill: Oh we know about those.















Now why is Paul editing a view? That's a developer task!

Basics of UI Design

Advanced UI Design

Chris Blatnick
Nathan Freeman

The two sessions were presented back to back, and Chris and Nathan continued on through the break.

A good UI should meet three main objectives

1. Usability - tasks are easy for users to find and accomplish
2. Likability - eye candy sells, make it pretty
3. Applicability - enhances their job and isn't an exercise in futility
   

If you don't have people who create UI's for you, change your title. You are a Designer, not a Programmer or Developer. You must build the user experience as an integral part of the development plan. Interface design is an iterative process. Keep examining the interface to make sure it is meeting the users' needs.

To make sure you meed user needs, engage in user interviews. If that isn't possible, use profiles and personas. You should spend time with the user to capture what they do, to ensure the requirements you receive actually match the work being done. You can use low fidelity prototyping, which means letting the users draw out screens with crayons, and usability testing of early prototypes to ensure you're on the right path. You should always have the UI worked out before you start working on the code.

Designing a good UI may be extra work, but it is our job to make the user experience better. You may get pushback on this by your boss, who says it will cost too much. Using low fidelity prototyping is very low cost and changes can be made easily. Fas iterations allow for a variety of approaches to be tried cheaply. The most important thing to know is that changes made after code is written is much more expensive to rewrite.

Font tips

• Be consistent. Don't use serifs.
• Use cross-platform fonts
• Use cross-language fonts
• Use fonts that have higher-resolutions available for accessibility
• Be gentle with styles, such as bold and italics. Drop shadows, emboss, or extrusion should NEVER be used with native Notes fonts. It just doesn't render it well.
• Use CASING to your advantage.
• Use different fonts in read and edit. For example, in Read mode make labels smaller and lighter than data, but in Edit mode make labels the same side as data, and darker.
• Hide some labels during read mode. People will figure out City [ ] State [ ] , Zip [ ] when they read it.

Whitespace is very important. Use table borders to push your tables away from the edge. Don't cram everything on the top left of the screen. Use fluid layouts via tables that are set to size to window and right and left align. Use right alignment to take advantage of high-resolution screens. You can use a separate form with fixed widths for printing if necessary.

You can use an editable column's InViewEdit event to display a dialog that edits the document to give quick access to common data.