If you have not seen the features list, check them out here. I think the most important items from that list is the tight integration between Windows Phone and Windows, the desktop version. According to various leaked info this layer will contain the kernel, networking stacks, security model, multi-core processor, and multimedia.
It would be interesting to see how much of it is true later this year.
Here’s an inspiration article about how to design a smartphone in a few minutes from Sami.
I especially like the last part about what it meant to design for the users. It is not about throwing a bunch of features together and calling it a product, it’s about thought-out, fully vetted features that package in a nice and usable UI.
InfoWorld published an interesting article last week where the author predicted the death of Windows Mobile 7, scheduled to be available later this year, and the author concluded that Microsoft should give up chasing the mobile space. While I agree with many points the author made in the article, but I have to disagree with the author because he failed to consider two important points.
1) Developers. Because of how Windows Phone 7 is architected, it will be able to leverage an army of .NET developers and making them Windows Phone developers.
2) Microsoft cannot afford to give up or even get left behind by the competitors in the Mobile space. This market is too big and too important for them to ignore, and the mobile screen is the third screen (after PC and TV) behind their master plan as they try to recapture the Internet/Cloud. I think we will see Microsoft being a very patient player in chasing this market, just as they are now with the search market.
So maybe Windows Mobile 7 will not capture the excitements when it is launched later this year, but not taking the platform seriously, only because it is late, is a mistake.
I saw an article on the New York Times website this week about how internecine (gotta love that word) fighting at Microsoft was stifling innovation. The article can be found here.
Innovation
Whether you love or you hate Microsoft, it would seem obvious that big companies can have a hard-time innovating since sometimes what you are innovating in one part of the company puts another part of the company in peril. Still, I’ve worked at largish companies (Sybase and Sun Microsystems) which managed to innovate in some key projects.
Sun Microsystems was an especially interesting place to observe how you could manage a wide variety of projects. I worked for a short time in the Software Division in the group responsible for the Solaris Java VM — the VM itself, not the libraries — back in the mid-90′s. One of the other engineers in the division told me that because software was a loss-leader for Sun, costing more to produce than they could ever re-coup in direct revenue, the executives adopted a strategy of “slow-boiling” new projects.
If a potential project showed promise, it was given just enough resources to keep it moving forwards, like having a stew simmering. Then, if there was a sudden need for the results of the project (“we need this new network credential library right now“), resources would be pulled and put onto the critical project to bring it to a rapid, roiling, effervescent boil.
Argue what you will about a strategy like this and the project management headaches this invites, I saw time and again how engineers would strive to innovate given their limited resource pool, knowing that if they were on the right track, they would be able to finish their ideas. This takes nimble management and leather-skinned developers to succeed.
Working now for a somewhat smaller company, I see the value in innovation and nimble thinking as we work feverishly to bring our new products forwards and to market.
Welcome to 2010! Hope you all had a great holiday
Below are two of my most favorite features in ILINX Capture 4 web client.
![clip_image001[5]](http://softwaredevelopmentforecm.files.wordpress.com/2010/01/clip_image0015.png "clip_image001[5]")
Detachable Viewer
ILINX Capture 4 now supports detachable viewer – enabling the indexing panel to be on one screen and the image on another screen.
Personalization
ILINX Capture 4 enables more configuration settings on the web client. Both scanning options and confirmation prompts are now configurable
There also a tons of other improvements under the cover both on the client and server, but I find myself using these two features above the most.
Hope this helps.
Distributed Capture & Document Capture
Capture is only a part of the ECM universe, but a crucial part nonetheless. Once a document is captured into an Enterprise Content Management system, it must be stored, perhaps put into a workflow process, archived, and made available for retrieval. Retrieval is in many ways the main thrust of an ECM system (no point putting it in there if you can’t ever see it again); retrieval is dependent on the index values associated it with it, which brings us back to capture.
Capture is the process of getting documents (and their data) into the system. Distributed Capture is the mechanism by which documents from a variety of locations (near and far) enter the system. The easiest way to do this is to utilize the file system. When different offices (or locations — work from home, anyone?) of a company are on the same network, specific locations on the shared file system can be designated for various purposes. Different directories can be used to input different kinds of documents.
This type of taxonomy works okay for existing electronic documents (Word files, spreadsheets, PDFs, etc); but what about hard-copy? The seemingly ubiquitous paper which exists in our so-called paperless office? Well, it needs to be scanned in. You want documents classified in a consistent manner, and the metadata (index values and other interesting info about the document) as accurate and as consistent as possible.
Consistency is key. When setting up a company-wide ECM system, it is a a key success indicator that everybody to follow the same set of procedures and guidelines involved in getting documents into the system. This can be accomplished by having a distributed capture system available.
The company I work for makes and sells a distributed capture system today. As we go through our roadmap discussions for where we want to take the product to solve customers’ future problems, we developers have have to grapple with some fundamental issues, mainly, what is the best technology to use as a platform.
It’s easy to imagine using the web to provide distributed document capture throughout your enterprise. You have centrally managed web servers. Everyone has a web browser on their computer (and cell phone, for that matter). In fact, anyone who’s ever attached a document using an html-based email program has already exercised the base technology necessary for a distributed capture system. One key advantage of Distributed Capture is that you get rid of paper at the source; take a moment to think about the implications of that. It’s okay, I’ll wait.
What else is needed…
There are two main improvements to simply uploading a document by way of a web page. One is the acquisition of the paper document, the other is the user-experience and business process to build into the hosting program. I’ll go into the physical acquisition in a later post, but the user-experience of a distributed capture system has to provide two things to be successful. It must be Dead Simple to Use and it must provide the functionality necessary to get good data into the system.
Our checking with users shows again and again that a single button is an attractive interface, with more functionality exposed as needed. One key question developers raise is what technology to build the interface in?
| Technology | Pros | Cons |
|---|---|---|
| HTML | Standards compliant, supported by all browsers. | Primarily a static user interface. AJAX can add some Zing to the interface, but is problematical in certain situations (back-button, anybody?) |
| Flash | Ubiquitous; Flash player in something like 90% of all browsers. | Began life as an animation scripting language, although ActionScript 3.0 is more sophisticated. IDE support is poor. Hard to get my head wrapped around the timeline model. |
| Silverlight | Microsoft integration and toolset. Microsoft has an army of developers working on tools and technologies; big changes in how Microsoft handles internet computing are emerging. | Current market adoption is a little slow. Microsoft talks the big talk about cross-platform now, but has a history of embracing, extending, then co-opting technology (in my opinion) |
| JavaFX | Ubiquitous. Many very good VM’s out there. | Java itself is well suited to backend, server-side development. UI is not Java’s strong-suit; AWT ring a bell? |
| Platform Specific Code | Leverage native functionality, look and feel. | Lots of code bases to implement and maintain. Cross-platform toolkits and libraries tend to dumb-down the functionality to the lowest-common denominator. |
I’m sure anybody reading this has ideas of their own about the pros and cons of the platforms listed out, and perhaps other ideas to add to the list. I welcome your comments.
It’s a fact of life: Developers don’t always understand the end-user experience. Software programmers, as a group, are more comfortable designing and writing code against a written specification.
“The spec says to put the log file in directory XYZ, so that’s where I’ll put the log file.”
We are all sometimes guilty of this kind of thinking: “Well, the project plan doesn’t require a UI for the config file, so maybe I can get away without one, even though I know it will make life easier for everybody but me (because I have to create it)…” but it will always return to bite you in the backside. If there’s a concern in the back of your mind that you are maybe not doing the right thing, don’t just rely on the written documentation, go check with somebody.
The developer doesn’t always have direct access to the customers (and sometimes for very good reasons), but on each and every project we undertake, there should be a person (or even a group in a large organization) who is the Customer Advocate.
The role of the Customer Advocate could be performed by the Project Manager, the QA Dept, Tech Support, the Product Marketing group, the Program Manager, or even, *gasp*, the customer. This role is crucial in helping make informed decisions about the product you are working on; this person is helping the customer “scratch” the “itch” which caused them to want to buy your product or engage your services.
Don’t just assume that your idea is going to work, check with somebody. A sample size of two is infinitely better than just you and your keyboard.
What brought all this to mind was a simple poll my boss sent out on LinkedIn, asking folks which additional vendor we might invite to our annual ECM Conference (NEXUS 2009). Instead of just guessing, he put out a poll.
Anybody who’s taken a Statistics class could argue with the methodology, but the point of this particular poll is not to predict a presidential election, but rather to solicit input and get some guidance.
This kind of thing can only make your software better.
If you want to see the LinkedIn Poll, you can try it out here
Martin O. Waldron
Program Manager, SW Development
ImageSource, Inc.
Most programmers I’ve worked with are delighted to fix bugs in their code. Yes, really. It’s the social interaction which goes with it which is often the root of the problem. This is always a tricky subject because by definition something isn’t working right when you have to report a bug; you, the user, are frustrated because the software is not working as you expected and you might have very little control over getting the issue resolved.
I came across an old web page this week on how to report bugs. This is written from the programmer’s point of view, and I can say that it’s pretty close. In discussing it internally at my company around the “virtual water cooler,” I was reminded of the occasional travails experienced by our own Tech Support group in supporting our customers and getting us developers the info we need to fix those bugs.
The previously mentioned article talks about how to provide information to the developer to enable them to fully understand (and recreate) the issue. Recreating the issue is paramount so that once it goes away, we know we actually fixed the problem.
My own version of the summary from the article is this:
It seems to be that there are some basic categories of bugs:
What else?
(The original article can be found here)
Martin O. Waldron
Program Manager, SW Development
ImageSource, Inc.
A while back, I was reading a web page about how to report bugs in a useful manner and I was thinking, this is a good post, but I already know this. I realize that after 20 years in the software business, I am still eager to learn new things. That’s the gift and the curse of a career in software development, there’s always something new and spiffy to learn, but you have to keep at it or get swept downstream.
Continual improvement is a key to success. As I told my kids when they were younger (they’re old and wise teenagers now), even Tiger Woods has a swing coach.
My parents met while working as reporters for the Atlanta Constitution newspaper after WWII. They were sometimes sent to cover a human interest type story which was not what you would call “breaking news.” The subject would sometime observe, “You all put a story in the paper a few years ago about this.” My mom said she would invariably reply “New folks moving to town all the time, chief.”
This brings me to my second point: passing on good information. If I know something well, and can recognize the good information when I see it, then good for me. Framing it for others to be able to make use of that hardwon wisdom is a whole different thing.
I’m starting a new category on this blog to highlight, reiterate, or refine information which may be out there, but could stand a burnishing or a revisit. After all, new folks are joining the software industry all the time…
Martin O. Waldron
Program Manager, SW Development
ImageSource, Inc.
Make it Dead Simple
The whole point of ECM (Electronic Content Management) is to manage electronic content, meaning you have to have a way to put information in and to get it back out. You will also need a way to control (restrict or grant) access to the data. The data going in to storage must be findable again.
The success of your ECM solution is predicated on the validity of the metadata which goes in with it.Simply put, metadata describes the content you are storing in a way which allows you to find it again.
Back in the day, my fellow propeller-heads and I used to joke about Write-Only storage, meaning that data could be written to a disk, but never read, which of course renders it useless. Just as useless as Write-Only storage is content which is unfindable, or, just as bad, is data which matches too many criteria. This also makes it hard to use.
When getting content into the system, it is imperative that good, solid metadata is entered into the system along with the data.
What’s the best way to get good metadata?
Your suggestions?
Martin O. Waldron
Program Manager, SW Development
ImageSource, Inc.
Click Button to Subscribe
