Posterous theme by Cory Watilo

chieftech's blog


Its not not about the technology | CC-BY

Filed under: spreadsheets

The table experience in social intranets

Last night I presentated at the NSW KM Forum, where I talked about the range of social intranet software options available on the market. While a lot of the subsquent conversation was about being social inside organisations, one of the more practical discussions was about the issue of working online with 'tables'... you know, like those you create in Word or Excel:

Excel
Creating tables and lists etc is a fairly common activity in the workplace. In fact, I suspect many people use tools like Excel more for organising information than they do actually number crunching. So if people are going to work effectively online together in a social intranet, then this type of functionality is an important requirement. Unfortuntely, creating and editing tables in rich text editors online has never been a fantastic experience but recently it has started to get a whole lot better.

Nothing yet beats a spreadsheet in terms of pure flexibility and tools, like sorting and calculations - so for really heavy lifting with tables you'll need to use a Web-based spreadsheet like Google Docs and Socialtext's Socialcalc, or embed a spreadsheet.

However, lets have a look at a few leading tools and how well they support tables:

Atlassian Confluence

The whole rich text editor has been given a massive upgrade in the latest version of Confluence and tables are a lot easier to use now that users don't need to worry about dealing with wiki markup (which has been removed in the new editor). Confluence's table editing is pretty good although Jive (see below) packs a few additional formatting features. However, as complete package Confluence also offers a range of file embedding, spreadsheet, charting, and task list macros that other platforms don't offer.

Confluence

Jive

Jive's table editor is still essentially based on HTML tables, however the user interface removes some of the complexity of fine detail formatting - you can set the padding, background colour, text alignment (horizontal and vertical), font and colour without feeling you are going anywhere near the HTML code.

Jive
Yammer

Not a lot of love from Yammer for tables, unfortunately. You'll need to make do with sharing spreadsheet files instead for anything more than dot points lists.

Yammer
"Generic"

Most other Web platforms use a common rich text editor plugin, like TinyMCE or CKEditor. Support for tables has improved in these plugins but IMHO vendors like Atlassian and Jive are still leading the way. Note: the editing experience on a particular platform will depend on the version of the rich text editor plugin supported and how it is configured.

Tinymce
As you can see, on a particular feature (and apparently simple one) like tables there is a lot of variability between different social intranet platforms. Is there a winner? Well, I wouldn't pick a platform on this feature alone but these are the sorts of requirements I want to understand when helping a client pick a platform. Its may sound like a minor detail, but if you want people to work online in your social intranets then its actually more important than some of the big ticket technical specs.

Do all enterprise tools have to solve single quantifiable problems?

The benefits of VisiCalc go beyond its humble origins as calculating paper. It represents a way of using computers that allows the user to ask 'what if' questions that would be too tedious to carry out by hand. Not only are such questions important in planning, they can be vital to the user in learning and coming to understand his own application.

Both the words 'serendipity' and 'synergy' are appropriate for VisiCalc. As VisiCalc evolved it showed us how effective personal computers can be as streamlined interactive tools. But, VisiCalc was not simply a lucky extrapolation of the basic ideas. Both authors of VisiCalc have extensive background in using large mainframes as personal computers and in creating systems to be used by large numbers of people with little training. Word processing background was of special importance since it provided experience in designing screen-based, highly interactive interfaces. More important for VisiCalc, it made us very aware of the need for a carefully designed and tuned user interface. This interface was constantly refined during the development process.

via frankston.com

I hadn't seen this paper by Bob Frankston before - presented in 1979 it introduced the world to a new fangled idea: the Visicalc spreadsheet. Apparently there weren't a lot of people around to hear the original presentation of this paper, but it is worth reading retrospectively. Diffusion of this innovation was slow to gather momentum, but some people could see the potential.

Why is this worth mentioning?

The personal computer it seams was a solution looking for a problem and the idea for Visicalc came from an idea for improving how individual people currently worked on tedious calculation tasks, rather then affecting the bottom line of a business. I particularly appreciate that the creators of Visicalc thought carefully about how users would interact with it and other software they already used (bearing in mind the limitations of the hardware at the time). In the end Visicalc didn't completely kill off the idea of either prepackaged solutions for personal computers or enterprise systems, but it is hard to imagine any business today where spreadsheets aren't still considered to be a critical tool. In many instances you could even argue that spreadsheets are more critical than any of the large, complex systems of record that many organisations invest in.

From this perspective, I can't but help draw parallels with social software and wonder if its a good idea that all enterprise tools have to solve single quantifiable problems?

BTW if you prefer, you can watch a 2009 re-reading of the paper by Bob Frankston - part 1 and part 2. You can find more Visicalc history on Dan Bricklin's site.

Hat tip David Weinberger.

The risk of not adopting social business software

Ever since security giant RSA was hacked last March, anti-virus researchers have been trying to get a copy of the malware used for the attack to study its method of infection. But RSA wasn’t cooperating, nor were the third-party forensic experts the company hired to investigate the breach.

This week Finnish security company F-Secure discovered that the file had been under their noses all along. Someone — the company assumes it was an employee of RSA or its parent firm, EMC — had uploaded the malware to an online virus scanning site back on March 19, a little over two weeks after RSA is believed to have been breached on March 3. The online scanner, VirusTotal, shares malware samples it receives with security vendors and malware researchers.

RSA had already revealed that it had been breached after attackers sent two different targeted phishing e-mails to four workers at its parent company EMC. The e-mails contained a malicious attachment that was identified in the subject line as “2011 Recruitment plan.xls.”

via wired.com

Despite all the sophisticated management information systems that have been deployed in organisations, tools like email and spreadsheets remain the lowest common denominator work tools for knowledge workers, particularly between organisations. Together, I look at these tools as the original social software and the hackers knew that the odds of getting a hit were in their favour because humans are fallible.

I have no idea how much the RSA SecurID hack has cost government and industry, but I imagine it was significant. But imagine if next generation social collaboration tools were the norm, with social objects shared through humanised systems - could this hack have been avoided? Would those users have paused to consider who was sending them information, before they opened the file?

I mean, we don't even have a ROI figure for email and spreadsheets - they are clearly risky technologies that should be banned until we know for certain...

Desktop tools critical to the "rapid-fire" investigation into the E. Coli breakout in Europe

The only type in common with both companies and all the mixtures was fenugreek.

That discovery sent EU investigators in pursuit of fenugreek seeds back down the European food chain, in a rapid-fire search that deployed personnel from eight countries’ food agencies as well as the ECDC, World Health Organization and the Food and Agriculture Organization of the United Nations. They drafted a detailed 4-page questionnaire that fed data into Excel spreadsheets and a relational database. They crunched (and crunched and crunched) the numbers, and this is what emerged:

All of the seeds came from a single shipment that left a port in Egypt almost 2 years earlier, on Nov. 24, 2009.

via wired.com

Interesting to note that following the E. coli outbreak in Europe, it all started with desktop tools (Excel) being used to collect data for the government investigation. Quoting directly from the European Food Safety Authority report (PDF) itself they used combination of tools:

Data on single parts of the food supply chain were gathered using spreadsheets (MS Excel) for each company. A relational database (HSQLDB version 2.2.4) was used to manage the data/information from the tracing. Additional processing was done using the statistical package SAS version 9.2.

Of course, you do wonder if the investigation could have happened even more quickly or even that the issue could have been pre-empted if Government 2.0 principles (open data, crowdsourcing) and technologies (Web 2.0) had been applied?

Despite this level of traceability, authorities are still concerned that this outbreak is actually not finished, because they couldn't trace every seed or batch that might be infected. Maybe there is still a necessary role for crowdsourcing in this instance that a traditional approach just can't scale to resolve?

Enterprise 2.0: Show me the money (a spreadsheet might help)

Media_httpfarm4staticflickrcom3178294233310645dda28d61jpg_benihhgdehejfbd

Looking at some of the early reflections on the Enterprise 2.0 conference, the point about return on investment (ROI) and benefits has come up time and time again.

Proponents of Enterprise 2.0 have heralded the shift in the discussion to this issue with offered few answers, but meanwhile the nay sayers continue to point and laugh saying ‘show me the money!’ These critics have pointed out that executives can see the tangible value of three-letter acronym systems, like CRM, ERP, MRP, etc, but not this vague slack sounding Enterprise 2.0 thing. The argument is that they don’t want this vague ‘social’ stuff, they want process specific systems that someone can give a no mucking around bottom line sales pitch business case for, using proper management sounding speak (e.g. speak like we do).

I’m going to step out of that crowd and suggest that perhaps we need to look at this a little differently. For the benefit of the nay sayers, I’ll try to stick with something they should be very familiar with - spreadsheets.

Historically (I’m talking IT years here), spreadsheets have been pretty much ignored by the research community. There is a small clique of researchers interested in spreadsheet risk (a real issue by the way, where financial transactions are concerned) and vendors who are interested in pointing out the problems so they can sell business intelligence solutions. But there is very, very little on the business benefits.

I had trouble finding recent figures, but today there must be absolutely millions of businesses around the world that quite literally run mission critical business processes using spreadsheets. If the City of London is a proxy for other global financial centres (PDF), then I think we can argue that the global economy runs on spreadsheets. In fact, a regulator actually stated:

"Spreadsheets are integral to the function and operation of the global financial system"

Which brings me to this point - the spreadsheet clearly has more than just some passing  value to organisations, it has vital importance.

But if this is true where is the business case for spreadsheets? Further, where is the neatly categorised list of definitive and all encompassing use cases? And I’d like a statement of ROI for each with that too.

Looking back at the history of the spreadsheet, the idea was inspired by observing the frustration and tedious process of a university professor creating a financial model on a blackboard. (hmm, sound like user centred design anyone?) Some people recognised the wider potential - an original review of VisiCalc said this:

“VisiCalc isn't as easy to use as prepackaged home accounting programs, because you're required to design both the layout and the formulas used by the program. Because it is not pre-packaged, however, it's infinitely more powerful and flexible than such programs. You can use VisiCalc to balance your checkbook, keep track of credit card purchases, calculate your net worth, do your taxes - the possibilities arc practically limitless. Using VisiCalc does require a minimum amount of programming skill, but it's far easier to prepare a VisiCalc model than to write an equivalent BASIC program.

Who should buy this program? At $200, it is almost as expensive as an Atari 80OXL. Anyone who has need for more than one accounting package, however, would do well to consider buying VisiCalc instead. With a minimum of effort, you can have VisiCalc performing most functions offered by the home accounting packages, and then some.”

But today, spreadsheets are more than just about numbers. Like cockroaches, spreadsheet have continued to thrive despite the growing (perceived) sophistication of modern enterprise information system. They record data, drive barely repeatable processes, they are spread around by email systems and people use them to address problems that other systems fail to solve. I promise you, the success of every high end TLA system is backed up by spreadsheets. These spreadsheets, often combined with collaboration tools, fill gaps not just in the agility of those TLA systems, but they support more fundamental information sharing and collaboration so that people can actually use and make use of those same systems.

For example, I worked on a strategic IT project for a large, global company where some idealists wanted to push for day 1 reporting from their financial system. But other wise and experienced voices in this field pointed out that day 2 or 3 should be the real aim. Why? Because they needed to collaborate and resolve issues in the data that was coming in from different parts of the organisation first before they committed that data. Note, the point of the argument wasn't that we shouldn't bother with the TLA system and just use spreadsheets, but simply that we should look at the holistic processes and often social/collaborative work practices involved.

Bringing this back to Enterprise 2.0 [or what ever your social software term of choice might be] I’m not suggesting the spreadsheet is an exact analogy. However, there are many similarities worth bearing in mind, particular around the concept of emergence that is at the centre of the Enterprise 2.0 definition:
  • Its what people do with it that adds value;
  • What you can do with it is only limited by your imagination (I’ll let you think about the implications of this);
  • Once you have the software, it doesn’t take a programmer to apply those ideas, although you might need a few superusers; and
  • Implemented incorrectly, it can introduce risks.
If you still don't agree, then I suggest you put your money where your mouth is: Have a go at suggesting to CFO’s that there is no sound evidence-based business case for the spreadsheets and in fact the evidence that does exist creates risk. The only sensible thing to do, and to avoid all this spreadsheet hype of course, is to immediately remove spreadsheets from the corporate network. And think of all that money we’ll save in licensing. That makes good business sense, doesn’t it?

What do you think?