Panaton Inc.

Conferencing is Broken!

We spend a lot of time on conference calls. Many are now skype, GoToMeeting or some other combination of screen-sharing and VOIP. Still, the great majority of conference call participants still connect using their cell phones.

This is especially true for people on the move, who are in-and-out of meetings, airplanes and airports, hotels and cars.

These are the people that need and use conferencing the most and for them it works badly.

Truly, really, awfully badly!

It seems we are stuck not so much with technology that is 10-15 years old, but with a way of accomplishing what we need to do that just does not make sense!

For example – we schedule conference calls in Outlook or Google calendar – and then have to hunt for the dial-in numbers and conference call IDs before we can join.

How many times have you rushed to wrap up one call, because you have back-to-back meetings and you are the "organizer" of the next call?

Do you get irritated when people trickle-in for 5-10 minutes on a call?

Have you ever had to hang-up a conference call to get though security at an airport?

How annoying is it to have to keep punching-in the same numbers 2-3 times, if your connection is bad and your call drops?

All of these irritations are unnecessary and can be overcome. Panaton is doing something about it. Stay tuned!

 

Identity Management – how information technology created a world of contradictions

After last week's Burton Catalyst conference in San Diego, it is clear that the topic of Identity Management is alive and well and still very, very controversial.

It is notable that in this one area of information systems technology most organizations have embraced the "lowest common denominator" solutions and at the same time made all parties unhappy with the results.

Individuals dread identity theft and at the same time are forced to provide their names and addresses to hundreds of websites, give social security numbers to numerous employers and financial services firms and share emails addresses with everyone. Yet none of the consumers of personal identity information can know if an individual's contact information is currently correct.

Corporate IT employs countless staff whose primary task is to provision user accounts, handle lost password requests and manage groups, roles and access to information and applications. They may even occasionally get around to cleaning up old accounts and dreaming of SSO.

Companies that do business online lose millions because of bad delivery addresses, fraudulent credit card transactions, phishing, viruses, trojans and man-in-the-middle attacks that render their investments in SSL certificates meaningless.

Marketing, yellow page and directory companies have no choice but to lobby for unpopular violation of privacy regulations because they do not how else to stay in business. One cannot but giggle when reading the typical web account registration form that simultaneously claims to "protect your privacy" and also ask your permission to "allow affiliates to send information on their products and services".

The credit reporting agencies are both the curse and blessing of the American economy – yet most individuals clearly understand that they are powerless to control their own identity – personal property that the credit agencies profit from with no recourse or compensation to the individual.

An individual's identity is an ephemeral and ever-changing reflection of one's collection of "friends", posts, comments, pictures and links across social networking sites.

SaaS vendors have no really practical way of knowing or controlling how many individuals use the same username and password and are dreadfully exposed to liability if and when authentication and authorization fails.

Regulatory compliance to numerous government and industry standards is a maze of contradictions spanning machine-to-machine authentication and authorization, employee provisioning, W3C standards of web services security and great variations in international and regional security and privacy requirements.

This interplay of competing yet complimentary business, social and technology needs represents a tremendous opportunity to provide impactful and very necessary systems integration services in the areas of identity management, systems and applications security and enterprise business process optimization.

The $30K "Practice Safe Software" New Year Special

Happy New Year!

It is only fitting to start the new year mentioning a topic that we have come across  over and over again in the old year - project instrumentation.

It is very surprising to find how few of our colleagues and customers practice, what we jokingly call, "safe software". The focus seems to always be on the date and cost of delivering the next milestone and little heed is paid to long term viability and maintenance.

The reasons for these behaviors can be many - invariably, however, if a company or project makes it past the 18th month mark, bad practices become the type of problem that ends up on the CxO's desk and mid-level managers start playing that particular variety of IT musical chairs game, usually known as "CYA".

We would like to offer a simple formula for "doing it right", and as a picture is worth a thousand words - here is an approach that has worked for us on many, many projects and is simple and painless enough to implement, without a major investment of time and money.

And to celebrate 2008 - we are pitching to all of you unsafe software practitioners out-there a $30K / 60-day "special". Call us, an in 8 weeks (or so),  at a fixed cost, we will put in place this type of instrumentation and train one of your team to manage it.

We will also extend to you (if you choose) a long-term, low-cost, monthly support agreement, so that you can rest assured that your critical software engineering instrumentation is supported and maintained with patches, backups and all other non-essential, but necessary to-do's.

Here are 3 simple questions you can ask (and experiments to perform) to determine if you are a good candidate for this:

    - How long does a new software developer take to be able to build one of your critical projects for the first time and how many hours of hand-holding form one of your experienced staff does it take? If you are in a web/scripting environment: "How long does it take for a new person to add a new "form" to your web UI product?" (This is a good experiment to conduct, actually - be skeptical of what your people will tell you - only a completely new person can really surface the facts here...)

  - If everyone on your engineering team got brand new computers tomorrow and was not allowed to retain any old hard drives - how long will it take to be productive again - and how many deadlines would you miss? (With our scheme, you can be sure to be back in business in 24 hours or less!)

    - Do you know when the last fully integrated version of your software was completed and can you rebuild form scratch at least one previous version that has "shipped" or has been "deployed". For the colleagues in the SAS space - how difficult is it to "roll back" a version that was just deployed?

We hope to hear from you soon!

Cheers!

Google Arrogance

I’ve seen it before. They were from Microsoft in 1996, Netscape in 1998, Ariba in 2000. Today they are from Google. They are talented, successful and very, very arrogant.

I went to a small trade show today in San Jose. From an industry with about 10 major and 20 minor players, about 50% were there. This is an industry that deals with a technology I have personally been making a living from since 1992, with some non-trivial size clients and actually deployed implementations under my belt. I have devised a simple litmus test, a “magic” question I always ask a vendor in this business. In most cases, for each vendor, I am reasonably certain that I know the answer in advance.

The question I ask serves two purposes. First - I try to find out if some dramatic technological change has occurred under the covers (in our business we have to stay on top of this sort of thing). Second and more importantly, I judge the corporate culture and the sales & marketing pitch.

The best way to find customers that are in trouble and could use our help is when you discover that their vendor is selling hot air at an average deal size of 6-digits and more.

Today, I received all the right answers, form all the usual suspects. The right answer in this case is “no, it does not do that”. Occasionally, a very well prepared presenter will add “but there is a simple way to accommodate for this”.

Then I walked up to the Google booth and seeing that there was no one talking to the two people on duty, politely asked about their new product. Then I asked the magic question.

The answer was amuzing – not because it was incorrect (I would have gladly accepted a “Yes, of course we can do that”), but because I was told that my question was meaningless! In fact, the exact words were not only telling me that “This makes no sense, no one would ever WANT to do this, therefore it is unnecessary…”, but I was told off in the arrogant and condescending tone of voice that my 5 year old recently started using with me, when I get a cartoon character wrong.

I realized that Google’s culture has crested the magic boundary of success that will inevitably lead to stagnation.  The naiveté of these guys was heartwarming in a way – after all, let’s be honest - we all try to measure ourselves against the greatest success stories of the day, and discovering that the grass is not THAT much greener on the other side appeals to the same instincts that drive envy and, in conjunction, arrogance. 

So here is my idea for a bumper sticker of the day: “Silicon Valley! Home of the great, who know it.”

Writing End User Applications

Over time we all develop best practices for whatever it is we do every day. For the last ten years or so we have tried to summarize the guidelines for writing applications, dealing with relational databases and other practitioner "learnings". For the benefit of our clients we would like to share some of our internal materials that are used as "rules of thumb".

Note that these rules apply to commercial work only - some of the guidelines, like licensing, are not valid for our open-source work.

Another disclaimer is in order - what follows is largely based on this author's personal belief that good software is best built in what I call "Agile-Benevolent Dictatorial Democracy". Or, using small words:

- Agile processes are good as long as documentation is not forgone;

- Ability for everyone to contribute ideas and opinions at any time is good;

- Dilution of ultimate responsibility for shipping a working product is bad;

- Responsibility without authority is bad;

Taking all of these into account means that good software is built by teams in which there is a clear and ultimate decision maker, who is able to triage daily tactical decisions and priorities as a balance between the must-ship date and quality of engineering.

So, without any further ado - here are the Rules of Thumb for Building "Fat" Applications. Many of them also apply to building browser based apps as well - in fact the difference is disappearing so fast, that we are likely to have a single unified guideline pretty soon.

Fat App Programming Rules of Thumb

(aka How I wish I could write UI Applications)

Version: June 6, 2007

Purpose

These guidelines are reasonably general, but specifically written for developing UI-centric applications. In other words the “client” side of client-server, or the “presentation layer” application.

Usage

These rules are axiomatic. They are expected to be followed in their exhaustive entirety. Cutting corners is of course possible but in a commercial environment should require specific in-writing approval on a case by case basis.

This document is written with enough detail so that the author can know exactly what it means – this does not necessarily mean that there is enough detail for other people to understand it. If it does not make sense – please ask - do not assume. Assumptions make bad excuses.

Rules in no particular order.

1. Easter Eggs.
   1. Easter eggs are absolutely prohibited.
2. Copyright in every source file.
   1. If you have not been given a text header, containing the proper copyright information to include in every source file, please ask immediately.
3. Version and Build number displayed prominently.
   1. The application will show prominently the version and build number as a part of the main UI.
4. Free and 3d party licensed tools
   1. Unless specifically authorized do not bother evaluating or assume that you can use any software or software component, which is licensed using a royalty scheme
   2. It is OK to evaluate libraries and components for which we can pay once and then use in an unlimited fashion, even if they seem to be very expensive
   3. GPL licensed code cannot be used
   4. LGPL licensed code may be used with specific approval on a case-by-case basis
   5. Mozilla licensed code cannot be used
   6. Apache licensed code can be used
   7. Anything else – ask first before using; Do not assume that is or is not OK to use; Please!
5. Maintainability
        Your work will be organized and documented well enough so that another      person can maintain it with a minimum amount of effort.
   1. This means that you must document APIs and their proper usage. Every class, function / method and variable must be commented in-code with sufficient detail so that I[1] can understand it.
   2. Dead code must be removed as soon as it is discovered.
   3. Clever algorithms and programming tricks are to be avoided.
   4. Write your code for readability, not for brevity.
   5. Writing code for performance overrides rules [c] and [d], but not [a]. In general the more “clever” you think your code is - the more documentation should be provided. When writing documentation, do assume that you are a genius and everyone else is retarded.
   6. The language in your comments, docs and sources must be free of profanity, racial slurs, anyone’s personal information or anything else that may make it unprintable to the general public;
   7. Use of Javadoc for Java is mandatory.
   8. Use of Doxygen for C++ is mandatory.
6. Testability
   1. Every piece of your code must be instrumented for automation testing. This includes all UI elements.
   2. When a bug is fixed the test suite must be updated, explicitly identifying which test number is added to cover a specific bug number. You must make every effort to guarantee that when a bug is fixed, it will be impossible to re-introduce it later.
   3. I[2] must be able to open any source file, point to a function/method and, within the comments in the source, find out where the corresponding test(s), that cover that piece of code are.
7. Performance
   1. All user actions are asynchronous – in other words the UI is NEVER blocked and waiting after a user action.
   2. All user actions are interruptible (browser style STOP)
   3. All user actions show a progress bar (browser style progress) (typically in window frame status area or some other less obtrusive UI element). The progress bar must correctly indicate percent completed, or processed item count vs. total item count / remaining item counts. It should appear to update logically and smoothly, rather than get stuck at 5% for 10 minutes, then jump to 90%. This may require a separate “total progress line” and a “current item progress” line.
   4. For those very rare user actions, for which it is not possible to know exactly what percentage of the work is completed, a progress bar will still be shown using an alternative “activity” visualization – for example a left-right “ping-pong” bar, or a round “ying-yang” spinner.
8. System resource footprint configurability
   1. The user must have the ability to configure the maximum acceptable %CPU, max RAM, max HDD usage and HDD bandwidth and max network bandwidth, which the application is allowed to use.
   2. The user must have the ability to configure overall priority for the application, separately for foreground and background mode, and indicate if the app should back off more or less aggressively in each mode, so  that other apps can execute.
9. Undo and redo
   1. A full user action undo & redo is required and assumed to be standard for the application.
   2. Undo / Redo covers every possible user action, including UI layout changes, fonts changes, all configuration changes, text edits, data entry, etc.
10. Drag and drop
    1. All data objects can be dragged and dropped to and from the OS context and other applications. This includes the “trash”, file folders, FTP transfer clients, editors, debuggers, PDF generators, etc. See “Actions on single items and collections” for additional requirements.
    2. Within the application, menu items can be dragged between menus and toolbar buttons between toolbars.
    3. In the application, highlighted text can be dragged and dropped between text entry fields.
    4. In the application, non-text data values, which may be modified using UI elements that have no text fields, can be dragged between the same type of entry area AND to and from text fields. For example a slider with a range of 1-100 can be dragged to a text field and when dropped it’s current value will appear in the field as a number.
11. Actions on single items and collections
    1. If an action can be performed on a single item, then it must be possible to perform the action on a collection of items.
    2. This means that if one thing can be dragged and dropped – then MANY things can be multi-selected (Shift- or Ctrl- clicked) and dragged and dropped.

    i. For example, dragging multiple items to a PDF generator icon will result in creating a single PDF, containing all items.

    ii. For example, dragging multiple items to a ZIP icon will create a ZIP containing all items.

    iii. For example, dragging multiple toolbar buttons from one toolbar to another is possible.

12. Configurability
    1. All configurations are stored in a single XML file
    2. Parts of the XML file can and will be encrypted
    3. Everything is configurable – options, layouts, color schemes, skins, etc.
    4. The configuration file is the mechanism used to customize configurations for mass deployments – this is why portions of it may be encrypted or signed, so that the end users may not change certain subset of options, or never see a subset of features/menus/options.
    5. The application must be reconfigurable without requiring a restart.
    6. Configuration changes are saved as soon as they are made – not only when the user exists the application.
    7. The user interface for making configuration changes is implemented as a separate application, completely out of process of the main app. When changes are made a “reload configuration” message is sent to the main app, which then re-reads the configuration and reconfigures itself. The only exception is when the user makes UI layout changes within the windows of the main app, using drag & drop facilities.
13. Menus, toolbars & shortcuts   
    
    1. Menus can be reordered and menu items can be added and removed from menus and sub-menus;
    2. Items existing in one sub-menu maybe dragged to another submenu;
    3. Every menu name and every item on all menu levels have associated keyboard  shortcuts (with standard visual letter underlining);
    4. In general the user must be able to use the application without a mouse;
    5. Toolbar buttons also have shortcuts and their buttons have versions for “Large Image”, “Small Image”, “Small Image & Text”, “Large Image & Text”, “Small Text Only”, “Large Text Only”, and the associated mouse-over, hover, grayed-out/disabled and other commonly needed states.
    6. Menu options and toolbar buttons are context sensitive and will be       automatically grayed out, if they represent actions, which are invalid       for the current user selection and/or application context.
    7. Toolbars and menus can be dragged to all four sides of the main application window or floated.
    8. Floated toolbars can be set to automatically render and align correctly on the right-left-top-or-bottom of the mail application window.
    9. Floated Toolbars have a transparency setting and a show/hide global shortcut;
14. Context Menus (aka right-click in Windows)
15. Help and balloons
    1. All help is context –driven.
             In other words, pressing the help button (F1 in Windows) does not bring the standard Help Start Page, with an empty search box and a table of contents, but rather a context pre-searched result list of relevant topics. For example, if the user has selected some text, then right-clicked and opened a “Properties Menu” and then “asked for help – the results should be relevant to the possible actions offered by the dialog. This means that every UI object must carry a context help search string. This also means that when help is requested a “logical OR” concatenation of these context help strings is submitted to the help search engine. Finally, these context help search strings must be externalized in the same manner as the UI texts for localization purposes.
    2. Hierarchical network enabled help.
             The typical desktop application carries a local copy of the help files, which in many cases is backed up by a (usually) more current web help system. A good help system should have multiple network based help server URLs registered for it. This allows corporate users to have a locally updated help server for the application, with additional custom content, so that in a large organization desktop help queries do not propagate to the outside internet, unless the in-house server is unavailable. Updates from the vendor are broadcast to the local help server and the desktops pick up the help updates locally. Of course, if the local help server is not available, the vendor one is automatically accessed. In terms of incrementing a desktop application to handle these use cases, it is only necessary to have the ability to register a prioritized list of URLs, using a “help://” protocol nomenclature.
    3. Balloon help must be available for all UI elements. User-configurable options for balloon show/hide timings must be present.
16. Saved file versioning
    1. If the application stores data (most do), hen by default at least one       previous version will be retained.
    2. The application will offer the user a configurable option to store a copy of the information they are working with automatically every “X” minutes.
    3. The application stores by default archive (revertible-to) versions of previous configurations. An archive configuration version is stored when the application shuts down, if it has changed from the previous version.
17. Localization and Internationalization
    1. By default the application supports Unicode strings;
    2. The application reads and writes UTF-8 formats; It’s configuration files are UTF-8 encoded XML;
    3. The application externalizes all UI strings and provides a text-file based translation facility, so that additional languages can be added by the  “end user”, if necessary. This includes externalizing the formats for  date/time and money.
    4. The application makes provisions in its UI layout management for right-to-left and top-down languages.
    5. When designing UI elements with text labels in English, add 35% extra width and 20% extra height to all containers to accommodate internationalized version;
    6. Always use a layout manager or proportional spacing for UI elements. Never hardcode x-y UI element sizes – they must all be calculated as a proportion of the main window (form) and optionally with respect to the user’s screen resolution.
18. Absolute conflict prevention
    1. Multiple versions of the application can be executed at the same time on the same system without conflicts.
    2. Multiple instances of the application can be executed on the same system – this should be a user-accessible option in the command line when launching the app.          
    3. If the application provides some of its sub-components as 3^rd party SDKs, and 3^rd parties have used them to create their own applications or application extensions, then there should be no way a 3^rd party app can create a conflict with the “native” application. This is a specific concern when using Windows COM and dealing with “DLL hell”.
    4. See “install by copy as a related requirement”.
19. Install  by copy
    1. The Windows Registry is a bad bad BAD thing – we do not use it unless we absolutely have to[3].
    2. Installation should be a mater of simply copying all of the application’s code to a directory and running the main executable from it.
    3. As a corollary – install by copy means that the application can run from read-only media – like a CD, without an install.
    4. It is sometimes necessary to obtain a “windows compatible” logo or certification and this requires that executables, shared libraries, user data and registry entries be placed in specific subdirectories on the user’s computer. The application should be a well behaved citizen of the native OS as much as possible, while sticking to the above requirements.
20. Accessibility
    1. This is one of the few optional sections. Accessibility for people with disabilities is relevant only if the software is targeted to the public sector. In general use this rule of thumb – if you are not going to ship more than 100,000 copies to state governments for use in educational programs, you probably do not have to worry about this section.
    2. An optional TTS mode would be available, in which content under the cursor is read through the computer speaker.
    3. An optional Large Font UI mode would be available, in which content under the cursor is magnified up to 10x.
    4. An optional “magnifier cursor” would be available to enlarge application UI;
21. Startup and Shutdown
    1. The application absolutely must launch in under 3 seconds – this means that no matter what data the app must load form disk or connect to – after 3 seconds the user can start interacting with it’s UI or switch to another application. The OS and user must not be blocked for more than 3 seconds under ANY circumstance.
    2. The application absolutely must shut itself down in 3 seconds or less. The Windows OS message of “Cannot End Application – click here to End” is absolutely verboten.
22. Exception Handling and Error Reporting
    1. The application should be “un-crash-able” – in other words, as much as possible, every function call should be in a try-catch block, with the assumption that an exception would be thrown there and must be handled.
    2. All caught exceptions will be written in a crash.log file, identifying the time, function name, arguments, app version, user id, etc.
    3. The application will be able to send these crash.log files to the vendor’s (this means us) QA server(s). In general, when the user is in trial mode or uses the app for free this info is sent automatically, when the user becomes a paying customer, they have the option of turning this off. The crash.log is used to debug user problems.
23. Usage pattern and Usability statistics
    1. The application will log usage patterns – aka click paths in order to provide the usability team quantitative data.
    2. The application will log user actions and their timing. In other words, the log format will have a timestamp + user action on each line.
    3. Like the crash.log data, free/eval copies will submit this info automatically, while paid users can turn it off.

---

[1] I use myself as an example of a person who can read code but does not write code daily.

[2] I use myself as an example of a person who can read code but does not write code daily.

[3] We “have to” when we are going for a “Designed to Work With” logo from Microsoft.

Top of the World at the Semantic Technology Conference + Amazon EC2 Release

This week we participated in the SemTech conference in San Jose. We shared a booth with our good friends and colleagues from OntoText. It is a rare to be at a trade show with the best product on the market - well it did happen - the Ontotext OWLIM semantic repository, (Panaton is the US integrator and reseller for Ontotext products), is currently the fastest rdf server on the market and the only one we are aware of that handles 1+ Billion triples with "full" forward inference.

Granted, this is a very big claim to make. Our confidence comes from the published benchmarks and invite everyone to download and validate.

Last, but not least, we have released the alpha of the companion KIM entity extractor, deployed as an Amazon EC2 instance. For the first time we will be able to offer semantic entity extraction as a service, with a utility pricing model. To give this a try - grab an article form your favorite news website and cut & paste its plain text here. (Please note that this is a rather simplistic demo - a real production app uses custom ontology and entity extraction model, of course).

Simple Ideas are the Best

We just came across a fantastic new product - hats off to Vizu http://www.vizu.com. Within 6 hours with Vizu, we were able to conduct a broad market survey that otherwise would have taken us weeks, cost us thousands of dollars and at the end - not given us as much confidence.

Here is what our results looked like (click image for full view):

With Vizu it took 15 minutes to set-up, 6 hours to execute and it cost ... well we are not saying - but we are already running a second poll over the weekend with a follow-up question.

Best of all, our data is meaningful - Vizu makes sure that the results are anchored by sounds statistics.

Vizu makes it easy to do business - the prices are clearly posted, the user interface is simple and easy, and you can complete your poll, target it, pay for it and run it without logging-in more than once.

It was a bit of a deja vu - as if we were using Google AdWords for the first time again...

Panaton Website Arrives

Welcome!

After several months of product demos, evaluations, custom designs and numerous discussions we finally decided that the best way to manage our partnership's web identity is:

1. To buy, not build; and
2. Embrace blog technology;

The reasoning was simple - we wanted the easiest and most cost effective platform that allows all of our partners and selected employees to contribute to the corporate web site. We also recognized that the best websites are the ones that constantly change and offer current information, thinking and content.

We will be building out our site in the coming weeks.
Please visit us often.