Lou Franco's ECM Imaging Blog

Chuck Hollis (VP of Technology Alliances at EMC) has some interesting thoughts on the move to clouds. Under "What IT Vendors Should Think About":

This shift in perspective forces a re-thinking in fundamental architectures, use cases and more when considering IT technology.  Some are better positioned than others, but vendors shouldn't fall into the trap that cloud represents just another way to sell the products you have today.

It's a different gig entirely.

Not only that, cloud products and services will be sold and supported entirely differently than is done today.  Customers using cloud services will want a usage-based model, not an up-front static investment model.  And organizations delivering cloud services to the marketplace will have unique business model problems getting their services up and running, and achieving critical mass.

EMC formed their a new business unit for their cloud strategy this year with their acquisition of Pi (and ex-MS exec Paul Maritz):

Upon completion of the acquisition, Pi founder and CEO Paul Maritz, will join EMC’s executive management team as President and General Manager of the newly formed Cloud Infrastructure and Services Division. Reporting to Joe Tucci, Maritz will continue to directly oversee development and operations for Pi, along with other key elements of EMC’s cloud computing strategy, which include the EMC Fortress SaaS infrastructure, the Mozy online backup service and other upcoming EMC cloud infrastructure systems and software offerings under development.

And for an idea of what might be coming, Howard Shao (founder of Documentum), had this to say about the challenges of ECM in the clouds:

1. ECM causes a substantially greater demand on SaaS storage requirements and on the capacity of the network. ECM payloads are typically multi-megabytes in size and users expect content to arrive within seconds.
2. Customers may insist that some types of content are stored on-premise. Customers may feel that very high value intellectual capital should not be stored off-premise. Personally, I think that this is unwise and I think that the concern will change over time - let's face it, if you have a decent SaaS provider then they should be able to protect your content better than you would ever be able to. That said, there are sometimes country-specific compliance requirements that may demand that some content is stored in a certain geographic location.
3. In order to provide adequate levels of security, compliance and performance, ECM systems will need to manage content that is on-premise and off-premise. This will have to occur in a way that is transparent to the end user.
4. The SaaS solutions will need to support tiered storage devices and repositories. Again, this needs to be done in a transparent way.

This is just four ways of saying that the cloud document storage won't be completely remote, and it will be interesting to see how that can be delivered in a way that doesn't negate the advantage of adopting cloud services.

EMC and IDC put together this study of the digital universe.Some interesting imaging tidbits:

The Financial Industry isn't imaging in comparison to the rest of their IT usage:

Take financial services, an industry synonymous with number crunching. Some of the most advanced computing takes place at brokerages, and some of the most meticulous record keeping occurs at insurance companies. Transactions involving trillions of dollars a day — equal to the world's annual gross economic output — are logged deep in the banking systems’ computers. This is one of the reasons an industry that generated 6% of worldwide gross output buys 20% of the world’s computers.

Yet for all this information processing, the financial services industry accounts for just 6% of the digital universe today and will fall to 3% by 2011. There is simply not enough imaging going on.

 Government and Healthcare imaging is growing:

Government and healthcare sectors are both heavily invested in imaging — surveillance and mapping in government, medical imaging and record archiving in healthcare. In healthcare, imaging databases are growing for two reasons: (1) growth of images per year (more patients, more scans) and (2) conversions of archived film images. A large hospital, like the Cleveland Clinic, might now have a petabyte-scale database of stored images and be adding to it as many as three terabytes a week.

Satellite imaging is growing rapidly

The U.S. government’s Center for Earth Resources Observation and Science has archives of three petabytes — mostly aerial photography and satellite images — and is growing at two terabytes a day.

Julia Lerman, who runs .NET Vermont and has presented at the Western MA .NET group (among other places, I'm sure), has written an article explaining how to use Ink on the web with Silverlight.

I had been doing a lot of work with Ink on the Web and was frustrated by the limitations and challenges of dealing with ActiveX. Putting the capabilities into Silverlight not only mean very easy deployment, but it removed the restriction for TabletPC O/S or even a Windows O/S, as well as a dependence on Internet Explorer.

It's not exactly zero-footprint, but since there is no way to interact with ink in pure HTML and JavaScript, I think this is an acceptable tradeoff. It's one of the more compelling arguments I've seen for Silverlight.

Jim King's Inside PDF blog is a great way to keep up with what's happening with PDF (especially standardization). Last week he detailed why extracting text from a PDF is so difficult:

PDF specifies text content of pages as glyphs not characters. That is, one of the appearances for an "a" is chosen by the creator of the PDF file by choosing a font from which the "a" glyph can be taken. PDF page contents do not specify characters such as just the Latin letter "a".  

The rub comes when we want to work with characters not glyphs. Unicode is widely used because it is a character encoding technology not a glyph encoding one. In fact, for many purposes, such as searching for text strings, we do not want to search by appearance but we want to search by the Latin letters (or commonly by the Unicode encoding of characters).

Of course, if you need to extract text from a PDF, there are tools that can do that for you.

I was just flipping through a new book on a specific mainstream technology from a major publisher. The topic is interesting to me and the book looks like it's probably fine, but I'll never know, because it's over 600 pages and I don't have the time to devote to this topic. I don't want to pick on this book, because it's not just this one, but pretty much all mainstream tech books.

It reminded me of this Martin Fowler post on Duplex Book style. In describing a new 883 page book:

But xUnit Test Patterns isn't as scary as it looks, because it's actually two books in one set of covers. [...] The first book is a narrative book, designed to be read "cover to cover". The narrative book is something small enough to be digestible, in xUnit Test Patterns it's 181 pages [...]. The second book is reference material, which is designed not be be read cover to cover (although some people do) but instead to be dipped into when needed. The idea is that you read the narrative book to get a good understanding of the field, then put it on your shelf so it's handy to grab when you need to delve into the reference section.

This is the style that the GoF Design Patterns book is written in as well, and I think it works great. Fowler goes on to talk about what it would mean to fully embrace the style (e.g. should it be physically two books, should the reference part be online only).

Fowler and the GoF probably both use this style because it's used by Christopher Alexander (the architect whose patterns books the software pattern movement borrows from heavily). In A Pattern Language, Alexander describes how the form of the patterns is designed for skimming through them -- each pattern has a bolded introductory paragraph, a bolded solution paragraph, and a labeled diagram of the solution. You only need to read the rest of the chapter if you are interested in the details.

But even without embracing duplex styles, I think tech books could be much shorter. Here's a list of some of the books on my shelf that look a half-inch wide (about the 200 page range):

• The C Programming Language, by Kernighan and Ritchie
• UML Distilled, by Martin Fowler
• JavaScript: The Good Parts, by Douglas Crockford
• Presentation Zen, by Garr Reynolds
• The Non-Designer's Design Book, by Robin Williams
  

I consider these books to be essential, and find myself picking them up over and over. Even the next step up in thickness (Designing Interfaces, by Jenifer Tidwell and Programming Collective Intelligence, by Toby Segaran) are very quick and enjoyable reads.

I'd like to see publishers try a 200 page book for topics that they usually address with a 600+ page one, and perhaps consider duplex styles if they feel they need to deliver a larger book. The issue is that they'd be going against the grain, but if they genuinely did a great job in a shorter format, I think the word of mouth would help -- like it did for O'Reilly's Head First series.

This is Part III in my quest to learn about Pecha Kucha presentations for my upcoming one at the Business of Software conference.

Part I: Some early tips
Part II: Reading sounds like reading

So here's a Pecha Kucha about the business value of AJAX based on a presentation that I gave at AIIM in 2007. The original talk was about 45 minutes long, and I can tell you the original slides had more text on them.

I reworked the slides in a Presentation Zen style a few months ago, and took it even further for this.

Next week I'll show you some slides from the original and how I reworked them.

Yesterday, I shared some tips about preparing a Pecha Kucha presentation.

So, I have finished my slides and written my script, and I'm trying to make a self-playing presentation out of it. The problem is, when I read the script it sounds like I'm reading a script. It's also kind of nerve-wracking to watch a stopwatch while I'm reading it.

Normally, when I give a presenation, I have some bullet points I want to make, but I don't write out the actual words, and I just do the presentation in a conversational tone. With a Pecha Kucha, that's pretty hard, because have exactly 20 seconds for each slide, and sometimes the timing matters (you want to lead into a slide just before it's shown, or you have something you want to say while the slide is still up).

The key is to know the content so well that you can basically spout it out without thinking. Then you can get into the moment and use your voice and body to accentuate what you are saying better. I'm going to reread the "delivery" section of Garr Reynolds's Presentation Zen.

I'm also starting to really see the value of not talking the whole way through. I think the empty space between words would be more powerful in a Pecha Kucha.

I'm still working on that for my AIIM presentation rewrite, so I'm not ready to post it yet.

In the meantime, check out this list of tips from a Pecha Kucha presenter and Garr Reynolds had this post on how presenting was like stand-up comedy.

I've been preparing for my Pecha Kucha at the Business of Software conference.

The idea behind Pecha Kucha is to keep presentations concise, the interest level up and to have many presenters sharing their ideas within the course of one night. Therefore the 20x20 Pecha Kucha format was created: each presenter is allowed a slideshow of 20 images, each shown for 20 seconds. This results in a total presentation time of 6 minutes 40 seconds on a stage before the next presenter is up.[wikipedia]

To try to get used to the style, I'm taking a presentation I gave at AIIM in 2007 and rewriting it as a Pecha Kucha.

I'm going to post it tomorrow, but I wanted to write this post about some tips:

1. Hone down the presentation to a single core message. In a Pecha Kucha, you really only have time to make one point.
   
   
2. Time your speaking voice. I've calculated that I can speak about 50 words in 20 seconds without having to go too fast. That means that the whole presentation is about 1000 words, which is really short. This constraint is really a blessing as you can just throw out anything that doesn't support your main point.
   
   
3. Get good images.  I've had great luck at this free image site.
   
   
4. If you're having problems finding images that make sense for non-visual topics, try searching for the emotion that you want your viewer to feel. I used "surprise" and "easy". Also, go from the emotion to something that you associate with that.
   
   
5. Practice. Practice. Practice.
   

AIIM just released InformationZen, a social network site for Information Management professionals. Here's my InformationZen page, if you want to link with me.

View my page on Information Zen

Alan Pelz-Sharpe of CMS Watch has an interesting article about the importance of ECM Imaging:

At many conferences, and regularly via e-mail, people ask me about imaging in the context of ECM. Imaging is the the major cost that most projects either forget about or dramatically under budget for. Partly this is due to the fact that during the buying process it's all too easy to get caught up in the flurry of believing that every file will soon be digital. Even though paper is clearly here to stay.

He goes on to point out where the costs lie:

[...] the scanner is the least of your concerns. The cost and complexity of capture do lie not in hardware. Rather, your bigger expense will come in the form of software -- software that processes the captured image, indexes it, and puts it through quality controls, and (in many cases) extracts data elements and instigates workflows.

At Atalasoft, we are big believers that you can implement the exact ECM Imaging solution you want by using toolkits, and that the overall costs will be lower if you do so. Obviously, to make that calculation, you need to know the total cost of the alternatives (licensing, customization, roll-out, user-productivity, on-going maintenance, etc.), and Alan is right that it is worth doing that calculation because the total costs and potential savings are significant.

So, I was lucky enough to secure a spot in the Pecha Kucha contest at the Business of Software Conference.

From the wikipedia:

The idea behind Pecha Kucha is to keep presentations concise, the interest level up and to have many presenters sharing their ideas within the course of one night. Therefore the 20x20 Pecha Kucha format was created: each presenter is allowed a slideshow of 20 images, each shown for 20 seconds. This results in a total presentation time of 6 minutes 40 seconds on a stage before the next presenter is up.

My topic is going to be the Eval Funnel. The premise is that there are lots of tools and techniques to take someone from Google to your site and from there to a conversion (commonly called the Sales Funnel)

If your conversion is to an evaluation (not a sale), you have to keep going (the Eval Funnel). I am going to talk about it what you can do generally, and what specific things matter if you sell to developers (as we do).

If you want to read more about Pecha Kucha, this Wired piece is good, and here is the presentation that the author made to try the technique out.

I'm sure Joel Spolsky has forgotten more about UI design than I'll ever know, but I'll take a shot any way. A few days ago he wrote this about disabling menu items:

Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled.

I actually got to this post through this thoughtful reply from Daniel Jalkut about why disabling menu items is usable:

Disabled menu items convey valuable information. Users who are skimming menus in order to figure out what to do are trained by years of experience to skim past disabled items and look for enabled ones instead. The more complex the application is, the more valuable this dichotomy becomes. In essence, disabling menu items gives application designers a means of “funneling” user attention to the actions in an application that will actually work at this moment in time.

And, he further goes on to make the distinction between usable and learnable interfaces. There are probably a lot of ways to think about it, but basically I reserve "usability" for productivity related issues that users who use a system a lot run into and "learnability" for first-time or occasional users. Daniel makes this point:

The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.

Generally, I agree. However, some applications never have experienced users (meaning users that use the application nearly every day for long periods of time). For me, the applications that need to have high user-productivity (usability) are Office, Visual Studio, my browsers, and a handful of websites. For others, I appreciate some help orienting me, and I wouldn't mind non-disabled menus that explain why they can't work. If your application is used only occasionally or mostly by first-timers, then concentrate on learnability and don't disable menu items.

It's not always that simple. For example, I have to use Photoshop and Gimp at my job, but not as a designer and only occasionally. Most people who use it for work probably keep it up all day and might find it to be very usable. For me, its steep learnability curve makes it hard to use. However, I think it's right for the authors of those applications to ignore me. They should disable menu items that cannot be used in the current context because they have a large number of users that use the application very frequently.

There is a third option though, one that I think gets both usability and learnability. Just do the operation of the menu. If the user is picking the menu item, then they think it makes sense -- figure out what they think the menu item should do and then do it, or as Joel once put it:

Thus, the cardinal axiom of all user interface design:

A user interface is well-designed when the program behaves exactly how the user thought it would.

While reading the blog articles cited above, I quickly checked the menu of my browser (IE 7.0) to see which items were disabled (image on the right). I don't know what "Security Report" and "International Website Address" do, and the status bar message for them gives no indication when these might be available. I even did a quick look in the help and Google, but I didn't find anything useful.

Of course, the help could be better, but really, I bet that you could generate a "Security Report" for any web page.  Maybe the report would be simple or not give much information, but I would like to see what a report might have. This is not the same as just popping up an error, which would not generate a report. If you wanted to have some explanation of why the it was so sparse, that's easily integrated into the report.

Another option is to not put the items into the menu to begin with. If these items are so rarely available, then they probably shouldn't even be there. IE already uses the status bar for website/context specific actions, and these could probably be relagated to a less obvious place.

So, I don't think it's a clear as never/always disable menu items. Personally, I try to always make the menu enabled and just do the operation (undo is essential if you do this pervasively), but I would certainly disable a menu item that could not possibly make sense (e.g. "Save" when no document is open or "Copy" when nothing is selected). If I was writing an application that was only used occasionally, then I would opt for Joel's suggestion of leaving all menu items enabled and using them as a way to explain the usage of the application.

Last March, I blogged about a speech David Pogue gave at AIIM.

David Pogue gave a talk on the power of simplicity. His recommendations: pre-sweat the details, count the taps (like Palm), and that simplicity sells. He gave iPod, iPhone, Tivo, and Wii as examples.  On that note, if you're at AIIM, come by our booth to win a super-simple Wii (and also see how simple it is to annotate documents on the web).

Looks like it was based on this presentation to TED in 2006. It's an excellent presentation and worth seeing both for his style and the content.

I started my first Google App Engine application this weekend. I wanted to jot down some initial thoughts and tips.

1. My experience with it was greatly enhanced by the fact that I have built web-sites with Python and Django, have some experience with other WSGI based web-frameworks.  Given that, Google's API just "makes sense"--meaning, it's what I expected. Anyway, aside from knowing the language, I already have my machine set up for developing this way -- and I have a basic sense of how to structure applications with API's like this.  I'm not sure what it'd be like if you were coming from just ASP.NET, since it's quite different.

2. If you are building the app on a Mac, I can't recommend the Google App Launcher highly enough. You can do everything it does with the command-line interface, but this makes it a lot easier.

3. Somewhat surprised that GQL doesn't support joins. Google claims that joins make it hard to distribute the database.

One big feature that you may have noticed that our Datastore doesn't have, though, is joins. The reason for this is that joins are usually a source of performance problems in a distributed system, when you go beyond a single machine: it's much harder to efficiently support a join on a distributed system that spans many computers and many hard disks.

That actually underscores the strength of the Datastore, and why what we are doing is exciting. The Datastore is built on Google infrastructure like GFS, the Google Distributed Filesystem, and Bigtable, our horizontally scalable distributed storage layer. You can read papers about both GFS and Bigtable online, if you'd like-- they're fascinating. The long and the short of it, though, is that Bigtable is a storage system that can be used to support queries like ours, but which doesn't run on a single computer, or even a sharded set of computers, like a SQL database does. Rather, it is a fault-tolerant, distributed system that can span tens of thousands of hard disks on thousands of machines, making all of them appear to be a single storage table. It moves your data around and restructures the system automatically to account for hotspots and increased storage.

What it all means, is that if you use the Datastore correctly, making efficient queries and thinking ahead a little bit about how your app will grow, the datastore will make it easy to scale your application as it grows, from a few entities to millions. No need to shard your databases, or to restructure your schema. This is part of how App Engine makes it easy to scale your web application from the ground up. 

I have to trust them on this, but I still have basically relational data. I feel like I'm going to basically re-implement joins if I don't find some guidance from Google on how to structure data. I really like their way of thinking of data (basically glorified stored associative arrays) because it's easy to imagine how to do iterative development with it. I have experimented with this in the past and the problems come later when you try to make it perform -- but with Google muscle behind it, maybe I don't have to worry about that.

4. Some easy way to handle payment processing is the obvious missing API (aside from things they aren't trying to do at all).

5. Really psyched that Memcached is there out of the box, also, their simple Imaging API is actually pretty useful for simple websites.