Systems Integration
Jul 30 2009
What I’d Tell Myself About Design If I Were Just Beginning
From all the time I’ve spent learning design, there are a handful of things I’d hope to remember or re-read if I were to ever get amnesia and have to start all over again. For new comers and experts alike, I’d like to share a few ideas about design worth thinking about through musings and links to other material that has helped form my opinions (some more relevant than others).
Jul 28 2009
The Power of Web Forms in Alfresco WCM
It pays to use a separate web form for each web content type.
My client uses web forms in Alfresco 3.0E to create web content. This means that when users want to create HTML (web content), they open an "authoring" form (defined ahead of time using XSD), populate its fields with the desired content, and save it. On save, Alfresco does two things:
- saves the content item as an XML file;
- transforms the XML to HTML using an XSL rendering template (also written beforehand).
Jul 24 2009
Back in April, there was an interesting article quoting Ron Jeffries et al on InfoQ looking at code reuse from an agile perspective. The conversation steered toward explaining reuse as a concern that is very expensive, looking at it from a top-down, “enterprise”-wide lens.
But is code reuse a black and white issue? My contention is there are varying degrees of reuse that are often neglected on a microscale within an even moderately-sized project. If the code you produce isn’t going to be reused, is it even going to be looked at? These are similar problems with similar solutions.
Jul 16 2009
How Users Approach an Application Interface
Developing an application interface for a system you are working on can be a labor of love. Many project teams will go to great effort to craft the best possible interface. From an ergonomic, functional, and aesthetic standpoint, they will pain over the most minute detail until their interface is "perfect". Unfortunately, many times users have other ideas as to whether the interface we develop is a good one. Here are some very basic guidelines project teams should keep in mind as they design their interface.
Users are much more pragmatic than we think in the way they approach an interface. Many times, particularly with our wording and graphics, project teams can tend to over-design an interface. With wording, we can tend to be too verbose and/or too creative. With graphics, we can tend to be too symbolic. Using terminology or graphics that are not obvious enough may seem creative but it can actually hinder the user in determining whether this is actually the content they were looking for. Which leads to the next point...
Users are not "consuming" your interface, they are "grazing". With a task in mind, users will scan an interface looking for meaningful words or images and then make a best guess as to whether that interface element is what they are looking for. Rather than considering whether their best guess is the correct action, most users take a trial and error approach. This is why it is very important to provide easy and accessible ways to undo an action (ex. Back button, Ctrl-Z, etc...).
Lastly, remember that you are NOT your user! This is perhaps the most obvious and, yet, most disregarded fact in user interface design. Project teams can let opinion and conjecture drive the design of an interface, or they can test it and let the data tell them what works. Usability evaluations and Information Architecture analysis should not be seen luxuries for serious project developement teams. You would no sooner push out code without testing it for bugs than you should release a design without vetting it with real users. Fresh eyes can show you things about your interface that you either didn't see or didn't want to see.
Check back for a future blog post about design guidelines that can help you tailor your application interface to typical user behavior patterns.
Jul 14 2009
easy spreadsheet processing with JExcel
To start you'll need to create a Workbook, which can be done by reading from a File or InputStream. Next, get each Sheet to process by calling .getSheets(). Need to be sure to close the workbook to free up resources by calling .close() once processing is complete.
Once you have a Sheet you can get each Row, which will be an Array of Cells and then get the contents of each Cell as a String. The API also gives you the ability to get a cell's value of a particular type (i.e. Number, Date, etc.). See the API documentation for examples.
*** Note - One downfall of the current version (2.6.10) is that it cannot read Microsoft 2007 Excel file version (.xlsx). Hopefully the next release will address this issue.
