Elegance Technologies Blog

Fast Formatter 1.2 released!

2008-03-14T10:00:00.002-04:00

We have released version 1.2 of Fast Formatter. This release add full support for Visual Studio 2008.

outsourcing article in Morning Call

2008-03-12T10:24:00.003-04:00

I am quoted in an article on outsourcing in the Morning Call,
which is a local newspaper in the Lehigh Valley. Check it out:

http://www.mcall.com/business/local/all-outsource.6218186mar12,0,6551465.story

Clif

Lucid Spec 1.5 released!

2008-02-07T10:17:00.000-05:00

We have released version 1.5 of Lucid Spec. Version 1.5 is a minor version upgrade that includes the following:

Added Date Picker widget.
Added Time Picker widget.
Added Full Screen mode so that you can expand the Simulation to take over the screen.
Added ability to add images and tables to text sections.
Improved Text Box widget with masked edit and password capabilities.
Improved Combo Box widget with always down and editable capabilities.
Improved Tree widget with optional icons for tree nodes.
Improved data file format to shrink files by up to 30%.
Fixed several problems related to Vista.

articles & presentations

2008-01-26T06:26:00.000-05:00

It's been a long time since I've posted anything. Here are some updates:

The BA Collective has just published a short article I wrote on Better Business Analysis through UI Prototyping.

I will be giving a presentation at Project Summit & Business Analyst World Philadelphia in April. I went to the PS&BA World Chicago meeting last fall and met plenty of interesting people.

Finally, we have a chapter on prototyping for web development in a book that should be published this Spring.

More details coming soon, I hope.

C-Sharpener For VB 2.3 released

2007-05-14T07:58:00.000-04:00

We have released a new version, 2.3, of C-Sharpener For VB. Version 2.3 is a minor version upgrade that includes the following:

Improved support for Microsoft Vista.
Improved code generation by removing unreachable code.
Added support Web Application project (Visual Studio 2005 only).
Added support for LBound and UBound VB translation.
Fixed error in casting.
Fixed error in handling of the split method.
Fixed exception if exe is present in the Solution.
Fixed XML exception.
Fixed error with two constructors being created for forms.
Fixed error with Page Load events in web projects (Visual Studio 2005 only).
Fixed error related to misplaced closing brace.
Fixed error with DateTime.

New website!

2007-03-08T08:00:00.000-05:00

We have just done a major redesign of our website. We hope that the website now looks more "modern". One thing we still have to do is make the blog design match or overall website design.

Please let us know if you have any suggestions for making it better.

Lucid Spec 1.4.0 released

2006-10-12T10:43:00.000-04:00

We have released Lucid Spec 1.4.0 today. It has the following new features and fixes:

Added Tool Bar widget.
Added ability to drag a widget from anywhere within the widget.
Added jump to capability to individual nodes in Combo Box, List Box and Text Spin widgets.
Added ability to copy/paste and drag/drop images to Screen Design.
Improved application look and feel.
Improved installer to optionally start application and tutorial.
Upgraded application to use .Net 2.0.
Fixed distorted Radio buttons and Check Boxes in printer output.
Fixed jump to problem in Grid Columns.
Fixed crash when Panels are rearranged.

Top ten tips for software prototyping

2006-06-13T13:30:00.000-04:00

Today's users have become more sophisticated. They don't want software that just works - they want software that is easy to use. A software prototype is useful for understanding the user interface and making it easier to use. Unfortunately, many managers, analysts, and developers don't understand how to efficiently create software prototypes. Here are the top ten tips to help you rapidly prototype software:

Start from a high-level requirements specification. This can be relatively short document with a few key use cases.
Start with screen flow. Don't worry about individual screens initially. Instead, try to figure out the number of screens and how the screens relate to each other.
Start with the most imporant screens. Identify the most important screens based on the most common use cases and prototype those first. Initially, your software prototype should ignore simple or infrequently used screens.
Start with low fidelity screens and refine. Your software prototype should be crude initially. Just get the right controls and text on the screen. You can worry about making the screens beautiful later.
Get feedback early and often. As soon as your software prototype has one or two screens, start showing them to users and other interested parties. Every time you add or revise screens, get feedback as soon as possible.
Involve real users. Make sure that you involve people that will actually use the system. If there is more than one type of user, make certain that you have a reprentative of each type. For instance, if managers use one part of the software and low-level employees use another part, then you need to review the relevant parts of the system with both managers and low-level employees.
Use a "fast" software prototyping tool. The software prototyping tool should be easy and fast to change. Otherwise, you will be reluctant to make necessary changes. We believe that our Lucid Spec product is the perfect tool :)
Pay attention to validation and business rules. Once you have prototyped screens and defined flow, you need to capture the validation and business rules of the system from users. You will usually identify missing features in your software prototype when you do this.
Finish with a functional specification. The functional specification should contain screen shots with additional validation and business rules. Review the functional specification one last time with users.
Use common sense. Always ask yourself "what is the least understand or riskest part of the software?" This will help you decide where to spend time on your software prototype.

Types of Software Specifications

2006-06-12T12:34:00.000-04:00

Developers often confuse the various types of software specifications. There are many types of software specifications, but here I'm focusing on describing the most common types: requirements, functional, and design.

Requirements Specification: Requirements Specifications are used to define the problem(s) that you need to solve. In other words, they define the "what". Requirements Specifications may contain both qualitative requirements (the software should be easy to use) and quantitive requirements (response time must be less than 2 seconds). They often contain high-level Use Cases.
Functional Specification: Functional Specifications define how you are going to resolve the Requirements Specifications. In other words, they define the "how". If a user interface is involved, they usually contain screenshots and descriptions of how the screens work. We (Elegance Technologies) created Lucid Spec to help write Functional Specifications.
Design Specification: Design Specifications define how you are going to implement the Functional Specifications. In other words, they also define the "how", but the "how" is related to software implementation issues. This software specification usually contains things like UML class diagrams, interaction diagrams, database design diagrams, etc.

Many software organizations use Agile software development processes today. As a result, some developers believe that they don't need to write software specifications anymore. This is not true! Developers may not write all the software specifications upfront, but they should write the portion of the software specifications relevant to their current software development iteration.

Lucid Spec 1.3.0 released

2006-05-30T11:37:00.000-04:00

We have released a version 1.3.0 of Lucid Spec today. The new version includes the following:

Added Hotspot, Numeric Spin, Scroll Bar, Slider, and Text Spin widgets.
Added ability to specify footnote numbers and control widget order in the widget table.
Added optional toolbar to the Requirements Panel.
Improved help file to include documentation on all widgets.
Improved consistency of Grid heading height.
Improved Screen and Section load performance.
Fixed pasting text incorrectly in Describe and Sections.
Fixed wrong font displaying in Describe and Sections.
Fixed crash when updating Screen names.
Fixed crash in Simulate mode.

Low vs. High Fidelity Prototyping

2006-05-03T08:08:00.000-04:00

In an earlier blog post, Roger said:

Therefore, I assumed that many users of Lucid Spec would request a low fidelity option to automatically morph all screens into a simple black and white style. I assumed wrong. In fact, not one user has requested this feature. I'm not really sure why this is. Are low fidelity prototypes something that you should do, but don't? Do people that create low fidelity prototypes only use paper? It remains a mystery to me.

There's good evidence (e.g. [1]) that low and high fidelity prototyping are basically equivalent in terms of finding usability issues, and low fidelity is much, much faster. On the other hand, other authors [2] recommend high-fidelity prototypes because they sell better to management & other stakeholders.

I think this is a key distinction - low fidelity is most efficient for finding & resolving problems, but high fidelity is most effective for persuading stakeholders.

I also think many people don't recognize the power of low fidelity prototyping. I recently led a workshop on prototyping for computing faculty and students. In one of the workshop activities, teams of participants spend 10 minutes creating a paper prototype, and 5-10 minutes reviewing it with a member of another team. Many of them were surprised by the issues and ideas that came up in such a short time. This is especially difficult for experienced programmers - we're conditioned to pay attention to little syntax details in our code, and it's hard to break such habits and create a quick and dirty prototype.

References
1. Miriam Walker, Leila Takayama, and James Landsey. High-fidelity or low-fidelity, paper or computer? Choosing attributes when testing web prototypes. Proceedings of the Human Factors and Ergonomics Society (HFES) 46th Annual Meeting, 661-665, 2002.
2. Jim Rudd and Scott Isensee. Twenty-two tips for a happier, healthier prototype. Interactions 1(1):35-40, 1994.

C-Sharpener For VB 2.2.0 released

2006-04-24T15:14:00.000-04:00

We released C-Sharpener For VB version 2.2.0 today. The new version includes the following:

Increased the trial limit to 1000 lines of code.
Improved handling of manifest files.
Improved installer for Visual Studio 2005 when Visual Studio 2003 is not installed (Visual Studio 2005 only).
Improved handling of long project paths.
Fixed several errors in parsing when multiple VB statements are on the same line separated by ":".
Fixed error in converting the "<>" operator.
Fixed error in converting local variables in a Case statement.
Fixed error in parsing Catch blocks.
Fixed error in updating language attributes in .aspx files (Visual Studio 2005 only).
Fixed error in converting For loops that decrement.
Fixed error in converting Try statements that have comments.
Fixed error in converting inconsistent accessors in partial classes (Visual Studio 2005 only).

Also, for a limited time, the Professional Edition comes with Fast Formatter for free!

Fast Formatter 1.1.0 released

2006-03-29T11:01:00.000-05:00

We have release the first commercial version of Fast Formatter. Fast Formatter rapidly and precisely reformats C# code in Visual Studio .Net 2005. You can find out more here:

http://www.elegancetech.com/ff.aspx

A single license costs $59.

We welcome any and all feedback!

Lucid Spec 1.2.0 released

2006-03-27T10:18:00.000-05:00

We have just released version 1.2.0 of Lucid Spec! It has the following new features and fixes:

Added automatic edit so that you can just start typing when certain text widgets (Textbox, Button, Groupbox, etc.) are selected.
Added customizable templates that you can select when you create a project.
Added context menu to Describe tab and Sections.
Added ability to show or hide footnote numbers.
Added standard footer for printing that can be hidden or displayed when editing.
Added menu option to reset all Panels to original size and position.
Added a Recently Opened Files menu option to the File menu option to make it quicker to open files that you recently opened.
Improved in-place editing of Labels, Buttons, etc. to use the display font while editing.
Improved the clarity and borders of the screenshots in the Describe tab and Sections.
Fixed problem with existing text not updating when fonts are changed in the Options dialog.
Fixed memory leaks.
Fixed problem with incorrect control sizes printing when you print a single Screen.

Lucid Spec - not just for software anymore...

2006-03-16T15:16:00.000-05:00

Although our original vision for Lucid Spec was focused on software user interfaces, I keep thinking about other applications, such as designing user interfaces for non-software products. Actually, it might be more accurate to say "for products that aren't software-only", since software is a key part of many physical products - think of cell phones, video players & recorders, televisions, etc.

VCR interface design is a bit odd - the front panel of the VCR usually has only a few controls, while the remote control usually has many more controls, and the front panel usually has a small, limited display, while almost anything can be displayed on the TV monitor. (Interestingly, our 15-year-old VCR finally died, and the new VCR/DVD replacement has no display - I miss the clock and timer - and many more front panel controls.)

Periodically I work on a VCR design in Lucid Spec. I use a template screen with crude drawings of three physical devices - a VCR, a remote, and the television monitor - and widgets for the various controls on each device. The big challenge so far is that a specific physical control tends to be modal - it performs different functions depending on some internal state of the system. For example, if the tape is stopped, the fast forward button causes it to advance very quickly without displaying anything, but if the tape is already playing, the same button causes it to play more quickly, or even to speed up.

I've thought about designing a cell phone in Lucid Spec, but that would be even worse - a typical cell phone has around 20 buttons to handle photos, calendar, contacts, phone settings, text messaging, and even phone calls...

Fast Formatter beta released!

2006-03-08T14:00:00.000-05:00

Consistent C# formatting makes code easier to read, which reduces development and maintenance costs. It also reflects positively on you and your team's ability and professionalism.

Today, we released a beta version of Fast Formatter. Fast Formatter makes code formatting painless by rapidly and precisely reformatting your C# code inside the comfort of Visual Studio .NET 2005. You and your team can use Fast Formatter on code you develop or on legacy code that you inherit.

The beta version is free and fully functional. You can find out more on our main website:

http://www.elegancetech.com/FF.aspx

We would really appreciate any comments or feedback that you have.

Low tech simulation logic in Lucid Spec

2006-02-24T17:53:00.000-05:00

In Lucid Spec, we're often trying to balance power and ease of use. Actually, it's less a matter of "either ... or" and more a matter of "both ... and" - we want novice users to be productive quickly, and we want experienced users to be productive in larger and more complex projects. We try to keep this in mind as we evaluate potential new features (thanks for your suggestions - please keep them coming!).

A good example is the issue of enhancing simulation capabilities. In the first release of Lucid Spec, most widgets (buttons, text fields, etc) have a "jump to" property - if the value of this property is a screen name, then Lucid Spec will jump to that screen when the widget is activated during simulation. A user can type the screen name, or select it from a menu. For example, a login screen typically has two text fields and a button or two - you enter a username and password, click on a button, and go on to the next screen in the application. Not surprisingly, we get requests and suggestions for more power and flexibility.

Some ideas involve saving user-supplied data on one screen so it can be reused later in the simulation. So if I enter "kussmaul" as my username on the login screen, I should be able to see "kussmaul" on other screens in the simulation. Would this be nice? Absolutely. Could we implement it in an easy-to-use-but-powerful fashion? Probably - although this is the sort of feature that can lead to more and more related features, until suddenly we've reinvented Visual Basic. Is it essential for GUI prototyping? I'm not so sure - it might encourage users to spend more time than they should early in the project.

Others present a bigger concern - suppose that data values I enter on one screen affect which screen I will see next? For example, the login screen might lead to different screens for different categories of users.
This sort of situation is pretty common, and there are several ways we might accomplish it:

Make multiple copies of the source screen (perhaps all based on a single master screen), each going to a different destination screen. This might be OK with a login screen for each category of users, but it gets more complicated quickly, and I try to avoid duplication.
Add widgets to the screen that won't be part of the final application, but can be used to select the appropriate destination. For example, the login screen could have buttons labeled "login as guest", "login as admin", "login as user", or an extra menu with these options. This approach could work on simple screens (especially if we use different colors or fonts to suggest that the extra widgets are someone different), but could interfere with the layout of crowded or more complex screens.
Use what I've been calling a "helper screen". When a user clicks on the login button, they see a screen with a menu or set of buttons that lets them choose the next screen in the simulation. I usually make helper screens with different background colors or fonts to emphasize that they won't be in the final application. In this approach, the simulated screens don't have to change, and we can support much more complex interactions with minimal duplication.

We could also extend the existing "jump to" capability in Lucid Spec to include some sort of selection logic that can use widget data values to determine the next screen. Once again, the slippery slope towards Visual Basic. Furthermore, we're trying to fix defects and make other enhancements, so we might not get to this right away.

If you have other ideas, or more reasons why we should enhance simulation logic sooner rather than later, please let us know!

The low fidelity non-feature in Lucid Spec

2006-02-14T11:30:00.000-05:00

I'm a big fan of the book Paper Prototyping by Carolyn Snyder. The book discusses how to create low fidelity (crude black and white) paper prototypes and then use the prototypes to get useful user feedback to better understand requirements and general usability. Joel of Joel On Software has said similar things about creating low fidelity functional specifications to flesh out design and usability issues. The basic idea is that low fidelity prototypes help users focus on how something is supposed to work rather than on whether something is pretty. You may have been in design meetings where users become focused on the color of a widget instead of whether that widget provides the necessary functionality. I know I have.

Therefore, I assumed that many users of Lucid Spec would request a low fidelity option to automatically morph all screens into a simple black and white style. I assumed wrong. In fact, not one user has requested this feature. I'm not really sure why this is. Are low fidelity prototypes something that you should do, but don't? Do people that create low fidelity prototypes only use paper? It remains a mystery to me.

Creating Lucid Spec documents for existing applications

2006-02-06T09:04:00.000-05:00

I spent several hours using Lucid Spec to explore possible enhancements to an existing application, and I'd like to describe some of the issues I encountered and how I approached them.

The application's user interface is similar to Outlook and other apps. There's a menu bar and tool bars across the top, a tree-like menu down the left side, and the remainder of the window contains a panel or a set of panels. The application performs complex, multi-step mappings, and I wanted to explore ways to help users visualize the steps and their contents. I didn't need to reproduce the entire application in Lucid Spec, but I did need to be able to simulate many of the key panels. I considered several approaches.

First, I could focus only on the parts of the app directly related to my goal of visualizing steps, and simply ignore everything else. This "low res" approach is a bit like paper prototyping. However, some of the people who would be looking at the spec might be confused by the visual differences - my quick low res mockup wouldn't look much like their familiar application.

Second, I could try to replicate large parts of the app in Lucid Spec, so that my mockup would look more like the actual application. Given the number of menu and toolbar items, and the complexity of many of the panels in the application, this would be difficult and time consuming, even if I didn't try to match all of the colors, styles, and fonts. This approach might make more sense if we were planning a complete GUI redesign, but it seemed like overkill for my more limited goals.

As usual, truth and beauty lie somewhere between the two extremes. I wanted something visually similar to the original app, but which would allow me to focus my time and attention on a few key pieces. This led to a third approach, which worked pretty well. I captured screenshots of the app (with SnagIt), imported them into LucidSpec, positioned transparent rectangles over the widgets that I needed to link to other screens in the short term, and then added new screens and widgets for new functionality. No problem!

Actually, it did take some work. All of my screenshots shared a menu bar and tool bars, and many also shared the menu on the left side of the screen. So first, I used SnagIt to remove the content panel from a screenshot (leaving the window frame, menu bar, and tool bars), and used that as the background image for a master screen in Lucid Spec. Second, I trimmed a screenshot so that it contained only the left menu, and inserted it as an image in a second master screen, based on the first. I then trimmed the other screenshots to show only the relevant panels, and inserted each as an image in a new screen, based on one of the first two master screens. Once I had all of the screens I needed, I went back to the master screens and added transparent rectangle widgets over the key controls, and linked them to the appropriate screens. I could now simulate the original flow between screens & panels! Using this as a basis, I started experimenting with other ways of presenting the steps and their contents.

I found myself wanting a callout or postit note widget that I could use to annotate the original screenshots.
One more thing for the future feature list for Lucid Spec, I suppose.

In the future, we might try to make this sort of project easier to accomplish in Lucid Spec. If this is something you need or would really like to see, or if you want to suggest possible approaches, please let us know!

Is Visual Basic destined to fade away?

2006-01-31T15:32:00.000-05:00

I'm bound to get in trouble for this post, but I'm going to try anyway. I believe that Visual Basic (VB) is destined to slowly fade away. Please bear with me while I explain my logic. My logic is based on market forces - it has nothing to do with the power of the VB language or my opinion of it.

Special Note to VB Programmers: For the record, I admit that I'm primarily a C# programmer, but please don't come to my house and lynch me for what I'm about to say. Thanks!

Historically, VB was created by Microsoft to make it easier to create Windows desktop applications. VB made it possible for both developers and non-developers to create new application that wouldn't have been able to do the work in C/C++ (the main alternative when the VB development environment launched). VB was nicely differentiated from C/C++; it wasn't as powerful as C/C++, but it was much easier and faster to use. Even C/C++ developers (who were usually language bigots) also used VB to create application prototypes.

Today, Microsoft (MS) has VB.Net and C# which are both based on the .Net Framework. VB developers switched to VB.Net and C++/C developers switched to C#. Both languages have the same underlying power and complexity because they are based on the same framework. In fact, VB.Net and C# are semantically equivalent; they only differ by syntax (and products like C-Sharpener For VB can convert between them). The differentiation between the two languages has disappeared.

The question is what language does a new developer choose to do desktop and web development on Windows? I think he or she will choose C# for two reasons. The first reason is that most new developers are learning Java in school which is syntatically similar to C#. It is an easier transition. The second reason is that most commercial development is done on Linux or Windows. Java is normally used for Linux and C# is used for Windows. A new developer would like to have some career flexibility. It is easier to keep both Java and C# in your head than Java and VB. Therefore, the new developer is more likely to pick C# than VB to maximize his career options.

As new developers choose C# over VB, the number of VB developers will slowly decline and VB will fade away.

Uhoh, I think I hear some VB programmers banging on my door; I have to go now. :)

How to get user feedback in Lucid Spec Player?

2006-01-27T08:32:00.000-05:00

The free Lucid Spec Player allows the authors of a Lucid Spec document to share it with other people (clients, colleagues, sub-constractors, etc - I'll call them all reviewers) who don't have the full Lucid Spec application. (Of course, we hope some of the reviewers will decide to get full copies of Lucid Spec...) The main reason to review the spec is to get feedback, and we've been thinking about different ways to capture feedback.

The most obvious approach is for the authors to sit with reviewers and watch them explore the spec. They can ask each other questions, clarify vague requirements or features, and brainstorm possible changes. This is easiest if everyone is in the same room, but can also work via web conferencing tools like Webex or Festoon.

Another approach is for the reviewers to write down comments and questions, and email them to the authors. We've gotten a lot of great feedback in this format for Lucid Spec, and we log it all in Trac. It takes a bit longer, and may disrupt the flow of simulating the application, especially if the reviewers have to wait for the authors to respond to questions.

We're thinking about ways that Lucid Spec (and especially the Player) could simplify this process. For example, Lucid Spec could generate feedback templates based on the document structure, so that reviewers could more easily comment on the spec, or even assign numerical ratings to specific pieces. Lucid Spec could also provide a way for reviewers to enter comments for each screen (perhaps with something like the Details panel), and an easy way to send those comments back to the authors, probably via email. We could also track the sequence of screens that reviewers examine (like the logs for web server), which could help the author understand what parts of the simulation attract the most attention.

In my experience, one of the best ways to improve a design is with rapid feedback and improvement. To quote Tom Peters: "test fast, fail fast, adjust fast". We'll continue to add features to Lucid Spec to make it easier to create and modify specifications, but we also need to find better ways to capture and use feedback.

Lucid Spec 1.1.0 Released

2006-01-20T14:28:00.000-05:00

We have released version 1.1.0 of Lucid Spec. This version contains an improved ability to configure the Grid and many bug fixes.

This is the first commercial release and we want to thank everybody that participated in beta testing. The feedback that we received was invaluable.

Welcome

2006-01-14T12:28:00.000-05:00

Welcome to the Elegance Technologies corporate blog. We will post here several times per month and discuss new product releases, tips, and general topics on software development.