I joined nMetric on a six-month contract to re-implement this page and its widgets with newer standards-based technologies (HTML5/CSS3/JQuery Widgets) to free it of the third-party proprietary technology it was utilizing. Coming from a strong UX design background I noticed room for improvement which I proactively offered suggestions for. Subsequently, I was given a free hand to redesign the entire UX of that page before actual implemention, working closely with the leadership team at nMetric to keep the design within context and their user requirements framework.

SO, HOW DID IT DO?
Development on the latest version of the nMetric scheduling system is ongoing, but at a recent demo to end-users, the audience have claimed they particularly appreciated the way the new landing page was operating given its dynamic and subtly animated user experience and pleasing visual design.

The success and early conclusion of the design and front-end implementation of this landing page prompted the leadership team at nMetric to assign another UX design project to me concerning a more complex semi-external helper application for their product.

MY 2 CENTS
This was a re-implementation and tech-update project that evolved into a UX design effort. As the only person involved in the design and interface development for the landing page, I was in direct contact with the leadership team to steer the UX in accordance with their user requirements framework, adding some functionality to and dropping some others from the previous version while generally enhancing the user experience using JQuery animation effects and an inviting design aesthetic.

CHALLENGES AND BOUNTY
Although I was mostly utilizing skills I had already aquired in the field of UX design and web interface development, I learned a lot as this was my first interaction with "The American Workplace", an experience that proved quite rewarding with the helpful, friendly, expert and fun-to-work-with co-workers I got to know there.

Technically, this also was the first time I developed an interface based entirely on JQuery widgets, a technology that I now strongly believe in and utilized again in the second assignment I did at nMetric.

The early and successful conclusion of my original project at nMetric prompted leadership to bump up the modernization of this tool from further down their roadmap. I was asked to apply the same UX approach I had towards their Landing Page to this sub-app while I was redesigning it from the ground up.

SO, HOW DID IT DO?
Although the back-end development work of this tool is ongoing as of late January 2012, since a large part of the designed interactions happen purely client-side (as a result of a clean and efficient architecture), I have been able to demonstrate %90 of the behavior of the new system and feedback from project stakeholders has been universally positive.

MY 2 CENTS
I was responsible for the UX and UI design of this tool as well as its front-end architecture and interface development. This project saw me working more closely with the software design team at nMetric than before, going through a few iterations before settling on a final design to implement.

CHALLENGES AND BOUNTY
The abstract, hierarchical and recursive nature of what was expected from nView presented interesting challenges in the development of its IA as well as presenting the need to develop a completely new take on the classic conditionally styled bar chart. This was an exercise in translating layered data to a readily consumable form for the user.

The visual design and overall UX of the tool was to follow guidelines already set by the Landing Page and were more easily developed.

As for the actual interface code, drawing on my experience working with jQuery widgets for the Landing Page, I developed two visualization widgets for nView: A two faceted 3D heat map and a highly specialized conditionally styled bar chart. Both of these widgets also had the ability the render their datasets as sparklines.

The main interface itself, being highly dynamic with minimal pre-coded markup, presented challenges of its own, but the final result was an architecture that could expose a high percentage of the designed interactions to the user with minimal AJAX round-trips.

In Iran, almost all work is done as a direct result of an official issuance of a letter and its circulation in an organization (outdated bureaucracy, I know). These letters can potentially travel long and extensively branched "forward" paths, every memo on the letters at each step of the way creating responsibility and therefore very important. Docu.Net was originally designed to handle such correspondence trees with features to create, sign, forward, find and most importantly track the circulation path and memo trail of these letters.

The full feature-set of this software is too long to include here but includes dynamic form creation and search, faxing and printing, full featured calendar and appointment management, web-based chat, informal correspondence system with Internet email support, unlimited organization tree size, separation of the concepts of staff position and person to facilitate seamless changes in the organization, instant messaging via SMS and a messenger client and custom saved-search folders to name a few. A huge, diverse and constantly in progress user experience design challenge that I'm proud to have been a part of.

SO, HOW DID IT DO?
Docu.Net has enjoyed nationwide success in Iran. It actually created its own market niche as there was no comparable web-based system at the time of its original launch in 2002 and has maintained a solid technical lead over competition that later emerged.

With a logical structuring of its many features and a highly intuitive, easy to use and uncluttered web interface, it owes much of its success to a fluid web experience.

MY 2 CENTS
I was a software design team member as well as presentation layer lead from its inception up to the time I left Iran. This is the product I've spent the most time working on during my career, overlooking seven different versions and providing wireframes and templates for a much improved 8th version. This latest iteration proposed an interface overhaul that would incorporate newer standards-based markup and scripting techniques. Fate brought me to the United States before I could see its full implementation.

CHALLENGES AND BOUNTY
Over the years, it became clear that the most difficult aspect of the role I was playing in the evolution of this software was maintaining design concept consistency over a long product lifespan.

How do you introduce new ideas to an application with a huge established user-base without alienating them? How can you maintain the identity of a product over several versions?

The entity named "Toorin Docu.Net" has remained unmistakably both "Toorin" and "Docu.Net" over 8 years and 3 major interface updates despite significant changes/upgrades/additions to underlying business logic and vast expansion of its feature set. This goal has required some tough choices and compromises, not all of them successful in terms of user acceptance; some choices falling short of expectations for timely innovations, some pushing the envelope a bit too far.

We researched and queried our user-base as much as we could - many new features were direct user requests due to our open customer service policy - but experience showed me that in the end nothing can match the quality of user experience decisions made in an organic, intuitive and user-empathetic manner while keeping in mind the long-term vision a company has for a certain product.

AN EXERCISE IN TABLE DESIGN
At its heart, MedStats was expected to display large tables of financial and operations data for a user-selectable list of practices. It would also have to be able to do calculations (like a spreadsheet) and comparisons on its rows and cells. It would also show basic bar charts via HTML and more complex pie's and graphs using server-side code that would create .gif files.

Obviously, high readability for these complex tables was necessary to help data entry and comprehensibility of the system. (Much of the data-entry was possible from the tables themselves instead of having separate forms.)

Practices would be able to see their ranking in terms of financial performance and operations efficiency, and another face of the system would provide tools for the firm to analyze the data and use the results in their decision-making process on how to help those practices achieve their full potential.

MY 2 CENTS
This was one of few Toorintan projects that I would have to personally do the whole presentation layer for, including implementation of underlying interface logic and connection with the lower layers of the software. The interface itself was designed for simplicity and speed, minimizing the use of graphics and reducing form clutter via extensive use of CSS.

CHALLENGES AND BOUNTY
Experience from the PracticeNet scheduler and schedule setup tables proved very helpful to me here as I created the live tables such as the one displayed in the first screenshot above. There were many use-cases where the table cells would be editable and design wise, this form of data-entry was very different from HTML forms of the day with their unsightly inset borders and bulky look and feel.

Although I was already an outspoken advocate for CSS, this was probably the first time that I based my whole approach towards web design on it so I could make the most of its presentation capabilities while keeping markup clean and staying away from graphics as much as possible.

AMBITIOUS GOALS FOR AN UNPROVEN WEB
Not many people believed it was possible to have large-scale applications natively on the web in 1996 when I started aiming for them. The resulting toolbox of web goodness was put to good use in the PracticeNet presentation layer which represented a rather uphill battle with new technology. This was a time when web-based reports from legacy applications represented the state of the art for most folk.

A huge system providing support for day to day management of OMS practices with multiple offices, PracticeNet included features to schedule appointments and the use of office medical equipment, track referrals, handle patient files and correspondence, track financial issues such as procedure payments and insurance, etc.

MY 2 CENTS
Most of the IA and interaction requirements of the system were already outlined by OMSP. As the web guy in our newly founded team at Toorin (Then called WebNative Software), I was tasked with figuring out how to pull off the implementation of a full-functioned software application presentation layer using only pure DHTML and .asp pages. Editable master/detail pages with search, complex multi-step modal and modeless dialogs, asynchronous page content updates (Ajax wasn't a term yet), popups, drag-selection for multiple-item actions and the like were all required as the original work done by OMSP was executed with a client/server application in mind.

CHALLENGES AND BOUNTY
PracticeNet provided a scheduler which played a central role in the system. It was coded as a potentially huge dynamic table of click-selectable and color-coded timeslots for a user selectable timeframe, expandable to view timeslots for all providers in all the offices of a practice. Assistants or healthcare providers themselves could add and manage appointments from this page. These appointments would usually take up more than one timeslot, and each could have a hovering sticky note attached which would pop up (based on user preference) when the appointment was selected.

The whole thing was a small .asp, Javascript and CSS marvel for the time, exposing a lot of interface logic, juggling all sorts of DOM tricks to readily highlight and select appointments for actions, float the sticky note or slide in the patient's (asynchronously loaded) information according to user preferences, provide mechanisms for finding open slots and setting appointments of various types, etc.

Another Javascript adventure was the creation of the Scheduler setup module which had a color-coded, drag-selectable table of the hours in a week, allowing users to apply previously set color codes for various appointment types so assistants would know, in the Scheduler, which types of appointments were appropriate for different times of the day/week. Only three colors came pre-defined: Gray for lockouts, blue for general appointments and black indicating the provider being scheduled at another office in the practice. Other colors would be user-assignable in the appointment types setup section and usable here as valid appointment type color codes. The resulting weekly color grid could then be used in the rendering of the Scheduler table.

All in all, this ambitious user interface pushed the boundaries of what I thought was possible for the web, and solidified my passion for creating web interfaces and the challenges involved while refraining from using orbital technologies such as MS Web Forms, Java Applets, Flash, and other so-called shortcuts.

Given the emergence of the strong push towards standards-based markup and scripting during the past few years, I can safely say I'm pretty glad I chose the path that I did with PracticeNet, and stuck to that path ever since, even during times when it proved difficult.

DESIGN FROM THE CONTENT OUT
The client had a very clear idea of what their target user group would be expecting and had prepared most of the necessary content before we started talking about the website itself and how to break down that content into a site structure. This allowed a very smooth and rather quick transition from a site information architecture design phase into a well-defined page design phase.

Simple and to the point, I was aiming for a clean, sharp and uncluttered design which would be refreshing to look at using cool blue and teal colors as well as easy to visually navigate and read with well-defined content areas and typography. (In retrospect, I would drop the paragraph justification though.)

MY 2 CENTS AND BOUNTY
This is one of few one-man projects that I've done as well as one of the quickest ones, the whole project taking less than a month from inception to launch. This speed was possible mostly because of the well-defined nature of the project which is usually difficult to achieve in most cases, but nonetheless proved to me just how valuable preparations and proper research is in ensuring a successful, quick and hassle-free process of creating websites.

IN A NUTSHELL
The client had a vision of creating a system like Alibaba.com to attract B2B customers, creating revenue by implementing a tiered subscription model based on the levels of information users could access about listed businesses. Businesses would list their offers to buy/sell merchandise or provide services and their prospective business partners would find and make contact via the site using methods depending on their tier.

MY 2 CENTS
This was a personal project I did for Raveh Sanaat Co., one of a handful of projects I handled as project manager in addition to my usual contributions as UI designer and presentation layer coder.

CHALLENGES AND BOUNTY
Complexities involving the interplay between the four user tiers (ranging from free to full), the three types of offers supported by the site and the fact that users could also be listed businesses themselves provided a challenging exercise in information architecture and user experience design. This was especially true for the user control panel where they would be able to view and - underlying business logic permitting - edit their own offers, requests and replies as well as track the correspondence chain pertaining to each one.

IEH is still live at http://www.iranexporthouse.org although it seems like it hasn't been maintained since 2005 and now exhibits some problems displaying in newer browsers.

THE BRIGHT FUTURE...
The TSE was familiar with our work via Docu.Net, our office automation software which they had been an early customer of. When they decided to upgrade their previous static website to a more modern one, they turned to us. We in turn proposed a concept with features such as live stock tickers and index graphs and a fully functional user area to handle trading, watchlists and analysis.

It would be a first in Iran in terms of technology and had all underlying systems figured out and ready to go.

...THAT WASN'T MEANT TO BE
The end that was awaiting this project is unfortunately common in Iran, and insurmountably political in nature. Although we were a small tech-oriented team of developers, Toorin inexplicably attracted high-profile clients in a word-of-mouth, tech boutique fashion and in Iran, most high profile and desirable clients are government organizations, all of them subject to the same complex political forces which wreak havoc on our international image on a daily basis. The short explanation is this: Depending on who is calling the shots, a highly important project such as this one can be labeled an unnecessary western luxury almost overnight.

MY 2 CENTS
My involvement in this project was as usual in Toorin projects, in the role of presentation layer lead and UI designer, and we had gone all the way to a working interface prototype, all wireframes implemented as templates with navigation in place, ready to receive final graphics, a cleanup and polish on the markup and styling, and to connect to the lower layers of the system. The screenshot above is still displaying the placeholder news section (from CNN/Money) which had also been designed, finalized and templated before the project was halted. Our version followed the same model for primary and secondary titles, meta information, article introduction and image placement but was different for the control panel exposing the save, email and print (we didn't have an article ranking mechanism) functionalities which were placed at the bottom of the article summary with different graphics.

FIRST IT WAS ONE THING, THEN ANOTHER
WebArch was designed to have a highly flexible/customizable information architecture. Its IA was minimal; users would create the rest by building personal archive folders with any number of user-defined properties, and have those properties be inherited and added to by sub-folders. Although it was designed primarily as a photo/scanned document archiver for its original client, the above mentioned ability effectively turned the system into an early online repository for any type of digital object and was purchased and used as such by future customers such as the Iranian Red Crescent Organization.

WebArch also provided public/private folder functionality giving users the ability to share folders with other users of the system or to open a folder completely for public view using design patterns much like what is seen in social networking websites today but with a more fine-grained approach to access rights to cater to its particular target user group.

MY 2 CENTS
My involvement in the actual coding of the presentation layer of this system was more limited than most Toorintan projects. I was generally focused on design aspects, providing wireframes and mockups that were later used in the final implementation.

CHALLENGES AND BOUNTY
WebArch's original client had requested that the interface be done on a dark navy background. The integration of this request with what we believed would work in a web application context presented a bit of a challenge. This was a time when we were trying to give web applications a desktop app look and feel rather than a website one to boost user acceptance of the new environment web browsers presented. The fact that this product was taken seriously by our domestic market as well as its original European client told us we could start being a bit more creative in our designs and move toward a friendlier website-looking concept in our other products which turned out to be the right thing to do.