Blogging Best Practices
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.
- 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.
- 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.
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 five new design elements:
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.
- Domino Connections
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.
- LS Debugger
- Formula editor
- Formula debugger
- Form/View script editors
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
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
- Usability - tasks are easy for users to find and accomplish
- Likability - eye candy sells, make it pretty
- Applicability - enhances their job and isn't an exercise in futility
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.
- 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.
You can use an editable column's InViewEdit event to display a dialog that edits the document to give quick access to common data.