Decompiled

Wikis are great for sharing, documenting and archiving information. We Recently launched one for our company’s intranet to improve communication and allow better collaboration. Because wikis are intended to be an open platform to promote communication and collaboration equally across the organization, we try to encourage everyone to contribute. Unfortunately, I quickly learned that people can have different ideas regarding good page format, or may not know how to properly format a page at all. This can quidkly lead to mess of unruly pages that are difficult to read and navigate. So, I put together a list of five tips that I thought would help make formating wiki page content a little easier and make the pages less challanging to read and navigate.

When creating a new page, or editing an existing one, keep these tips in mind.

1. Say No To Word: Unless the wiki has a built-in feature to deal gracefully with Microsoft Word syntax, Please Please Please…avoid copy-and-paste from word documents. Word documents create ugly HTML syntax that is difficult to edit and manage within the wiki (or any wysiwyg or web editor for that matter). It also creates pages that are structurally difficult to read and navigate without additional formatting and editing. As an alternative, save word documents as Rich Text Files, or plain text files then copy-and-paste into the wiki from there, then edit and format the content in the wiki using the wiki editing tools.
2. Use Headers and sub-headers: Add headers and sub-headers when appropriate to organize your content on the wiki page. Using headers will not only help to visually separate each important section of your page, but they will also auto-create a page index or TOC (Table of contents) making it easy for users to find and navigate page content.
3. Making The list: Use Ordered (numbered) lists and Unordered (bulleted) lists when creating lists of items. This makes each item in a list easy to identify and improves readability.
4. Use An Opening Introduction: If your creating a new wiki page, always try include some information in a small paragraph at the top of each page describing what the content is about, and how it can be used. It is also helpful to include a small description below each heading and sub-heading as well. This helps readers to quickly identify the content and how it can be used.
5. Can I Quote You On That? : Provide citations and supporting links to references when possible. Besides giving credit where credit is due, citations allows readers to confirm the validity of your input and lead them to additional sources of reference.

Do you have any other tips? Please leave a comment and share them here.

I was recently asked “why only allow plain text email formats for not only reading messages received, but also for our bulk outbound messages”. Apparently, some of the natives have grown restless and want to include large bold colorful type and pictures and bells and whistles with their messages. Whats the problem with that? Well, there are several.

I’m pretty sure that most people (I’m talking average people here) don’t know what HTML even means, never mind how to properly write and test it. HTML is the mark up language used for writing web pages, not email messages. It has a specific form, syntax, structure, and should conform to current standards. If not written correctly, you will experience problems of one sort or another. Then there is the problem of writing for different displays, engines, platforms etc. Each of these also introduces their own set of quirks, hacks and workarounds.

HTML email also has a history of security related vulnerabilities and issues, for example:

• embeded content
• scripts
• the ability to include links whose text is different from it’s target
• tracking and beacons

It’s no secret that Microsoft has released warnings on a number of seperate occasions stating that opening a specially crafted HTML email messages in their popular email software would lead to your system being compromised “just by opening the message”. That’s it, end of story. (this is not an invitation to bash microsoft)

HTML is also popular with SPAM and PHISING and because of that, spam filters are likely to give HTML messages a much higher SPAM score, increasing the chances of that message getting buried by a filter.

These are very generic samples and I could write pages on the subject but they also give an example of how inbound HTML can represent a security risk and how outbound messages are put at an increased risk of not reaching the target, or being unreadable.

According to RFC 2822, plain text is the default format for email and therefore is supported in all compliant readers. HTML formats however are not required to be supported. There is also an issue of non-standard support and proprietary rules among HTML rendering engines and software, which introduces compatibility issues and broken pages or layouts or even in some cases, completely blank pages.

Here’s my perspective. If the intention, and ultimately your business, is to get your message to your target or audience, don’t you want to know that they will be able to read it. Plain text gives you that guarantee. HTML is not as reliable.

So what do you think?

• Do you prefer HTML email over Plain Text?
• Does your company disable or limit inbound HTML email?

Today I learned that Google is testing a new Free Mapping Service that will enable mobile phone users to determine their approximate location and retrieve mapping information without the use of GPS. Google continues to amaze me with their new products, ideas and innovation.

The details of how this all works are still unknown to me, but it has been speculated that that “general” location or area will be determined based on the closest receiving cell tower. Google has referred to this “general” location as “neighborhood-level information”. Sure, you won’t be able to get specific long/lat location, but (and this is my own speculation) you can get close enough to determine what shops, restaurants, events, etc (read consumables) are in the “general” area, and maybe develop an ad service suggesting locations of interest based on the users profile, habits, etc.. You know the typical song and dance.

Heres another hook. For all this to work, the mobile user will be required to download and install Google’s Free software on their mobile phones to use the service. Now I don’t know about you, but this is screaming “ANDROID!!!” Android is Google’s ambitious open source call to a mobile phone operating system. If your not familiar with Android, see my earlier post.

Finally, take into account Google’s announcement to bid on on wireless spectrum in the 700MHz band in late January when the U.S. Federal Communications Commission begins auctioning that resource, and things start to add up. This isin’t much of a surprise because Google had dropped some nuggets of information in the recent past showing some interest in this, but it was always unclear as to why.

Heres my take. Google has the collective resources to feel the winds of change surrounding their core internet based services. Users are not tied to their computers anymore. We are sharing information and data, collaborating across devices and platforms, making phone calls from our computers and browsing the web on our phones. Google sees the opportunity here and wants a piece - The First Piece. Traditional service providers are scrambling to change their business models to adapt to the open exchange and this is where Google has the advantage and always has. Google has developed some strong strategic alliances on the internet and mobile playing fields, and now they (Google) are putting all the pieces together. Don’t get me wrong. It won’t be easy, and there is a long road ahead for them, and many who would love to see them stumble. Either way, Google is about to shake things up.