Friday, October 29, 2010

How to avoid Information Overload

In the daily course of our works, we come across numerous emails from colleagues and clients as well as countless other unsavory emails uncaught by the junk filters. For the most part, it’s quick and easy to spot those unsavory emails and press the DEL key.

We all know the popular sayings of “Knowledge = Power” and what is knowledge if not information? It implies, then, that having too much knowledge is a bad thing. The real problem is that we often get copied on messages that our friends and colleagues think would help us in our daily duties when in reality they hinder us from completing our tasks effectively and timely. Then there’s the problem of people conversing using emails instead of using the more immediate communication tools such as instant messenger, phone or even simply walking-by for a chat(when it seems a walk-by-and-chat is appropriate).

So when we do get in the crossfire of people’s conversation emails—even when we are in the same project team, conversation circle, etc.—it pays to first know at the beginning whether we really want or even needed to participate in the essence of the conversation. Generally speaking, unless specifically addressed and called to answer a specific question, the simplest thing to do is to decide not to read it and any of the subsequent correspondence within the same thread. And thread is the keyword here.

Most modern email clients feature the ability to organize emails so they look like forum message threads. That’s the first and foremost what I personally do. Keeps things easy to quickly eyeball.

Second, we can (single-click) tag or flag emails that at quick glances seem important to revisit later. Forget about creating folders to categorize those emails. It takes more time than we think we have and won’t necessarily work as emails come faster than our ability to move them to the appropriate folder, especially not when today’s email clients have improved search function that can automatically create smart folders to contain the results of our searches. If anything, we’d be better off ignoring emails whose subjects are too generic to be useful as they indicate no forethought about the email itself. If one sender can’t take one minute to write a proper subject line, why must N recipients spend even one minute trying to decide whether it is worth spending more time to read and understand. It simply would be a disservice (not to mention costly in real terms) to our boss and other colleagues who are expecting us to perform our duties timely and productively unhindered by fly-by emails.

Third, also we can a mental note who among our colleagues are frequent offenders so that when email messages come from them, we can make an educated guess the likely importance of those messages and act accordingly.

Lastly, don’t return the favor, i.e., if we don’t like being blindly copied on messages that we think are not important to us then when we do get involved in an email conversation, remove all other recipients names except for the one with whom we are having it. I am a proponent of respecting everyone’s time and summarizing the conclusion of the conversation in a single email and creating a single attachment for the conversation, if we want to inform the team such conversation had taken place only for a matter of historical curiosity.

More often than not, we’ll be appreciated for not being party to exacerbating the condition of everyone else’s information overload. And most importantly, by going through the aforementioned steps regularly and consistently, we build for ourselves a habit to reduce our own being overwhelmed by things we’re unable to decide their importance.

Monday, October 04, 2010

Simple Creative-Interactive Development Approach

Preproduction:

· Brainstorm quick engagement rules.
· Gather and generate content.
· Construct the site map.
· Develop and approve and interface.
· Determine technical needs.

Production:

· Develop and refine content.
· Establish development, staging, and hosting resources.
· Get graphics production underway.
· Produce server-side support.
· Produce interactive materials.

Publication:

· Test cross-platform and cross-browser compatibility.
· Functional code review.
· Feature review.
· Coding style code review.
· Content (copy & graphics) review.
· Sign-off and deploy.

Post-Publication:

· Schedule maintenance periods.
· Schedule updates and fixes.
· Add content regularly.
· Promote site to targeted audience.
· Discuss expansion and re-design.

Organize and interview feedback and focus groups:

· Internal employees to provide management and organization needs.
· Public audience to provide likes, dislikes, and wish list.

Reuse:

· Create inventory of all existing content (brochures, graphics, interactive media, etc.).

Scheduling:

· Adherence to development schedule is a must; only one exception is allowed: unforeseen technical difficulties.

Project management:

· Although many stakeholders, there should only be single-point of authority in order to have:

  1. a final-say decision-maker; or,
  2. a tie-breaker in a round-table project discussion group.

Wednesday, September 08, 2010

Analysis and Specification Principles

More often than not, a project suffers not because of its lack of merit rather from miscommunication of intents causing grave consequences. If only we concentrate more at analyzing the subject area at the onset of a project, its probability for success can increase substantively.

1. Information Domain representation

a. Information Content and Relationships

This refers to the data themselves and their relationships to one another. For example: A “Paycheck” is composed of several pieces of data attributes belonging to different data objects such as: Employee {id, name}, Bank {name, routing number}, Instruction {net amount paid, date}, etc.

b. Information Flow

This refers to the manner in which data and their state are transformed by control objects or functions as they move through different points in the system.

c. Information Structure

This refers to the internal organization of the data and their state. For example: A “Paycheck” data could be organized in a single data table or object or in three different data tables or objects such as Employee, Bank, and Instruction and have their attributes linked to make what will be understood as a Paycheck object.

2. Models

Models are aspects of the information domain. They are abstractions that highlight important system requirements. Typically, several models are developed during requirements analysis and included in a requirements specification using a combination of graphical notations and textual annotations that may be plain natural language, e.g. English and/or a more structured language resembling a pseudo-code.

a. Functional Model

A functional model focuses on the data transformational functions in the system.

b. Behavioral Model

A behavior model focuses on the system state and event handlings (internal and external as well as user-invoked and systemic).

3. Specification partitions

a. Entity-Relationship Diagrams (ERDs) to represent Information Content and Relationships;

b. Data Dictionaries (DDs) to represent some information about Information Structure;

c. Data Flow Diagrams (DFDs) and Process Specifications, as functional models, and State Transition Diagrams as behavioral models representing information about Information Flow.

4. The Analysis and Specification Progress should cover Essential Requirements to Implementation Details in the spectrum

a. Essential Requirements

This refers to information about what needs to be done or to have (not how) with the basic understanding that human beings and other systems that the system with whom the system interacts are imperfect.

b. Implementation Details

This refers to the information about how the what will be addressed by the system.

Wednesday, April 21, 2010

How to create an Excel file programmatically (Part 2)

Offce 2003 XML method

This method is as simple as saving an .xls file into a template .xml format. When we open the saved XML file, we'll see a rather simple format to follow and places where we can insert new data rows.

<!--xml version="1.0"?--> <!--mso-application progid="Excel.Sheet"?--> <Workbook xmlns="urn:schemas-microsoft-com:office:spreadsheet" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:html="http://www.w3.org/TR/REC-html40"> <DocumentProperties xmlns="urn:schemas-microsoft-com:office:office" /> <ExcelWorkbook xmlns="urn:schemas-microsoft-com:office:excel" /> <Styles> <Style />... </Styles> <Worksheet ss:Name="Sheet1"> ... {Data table location} <WorksheetOptions /> </Worksheet> </Workbook>

All we have to do then is insert the data table in the XML dialect below, which while different from (X)HTML is still relatively easy to understand and follow.

<Table ss:ExpandedColumnCount="3" ss:ExpandedRowCount="2" x:FullColumns="1" x:FullRows="1" ss:DefaultRowHeight="15"> <Column ss:Width="107.25"/> <Column ss:Width="106.5"/> <Column ss:Width="21"/> <Row> <Cell><Data ss:Type="String">This is Cell A1 in Excel</Data></Cell> <Cell><Data ss:Type="String">This is Cell B1 in Excel</Data></Cell> </Row> <Row> <Cell><Data ss:Type="Number">123</Data></Cell> <Cell><Data ss:Type="Number">456</Data></Cell> <Cell ss:Formula="=RC[-2]+RC[-1]"><Data ss:Type="Number">579</Data></Cell> </Row> </Table>

But even if we don't use Excel's own dialect of table elements, we can still easily substitute in regular HTML (4.0) tags as indicated in the namespace declaration near the beginning of the XML document above:

<Workbook ... xmlns:html=".../REC-html40">

All in all, it's still relatively simple to do.

(Part 3)The OpenXML approach, however, isn't as simple (for me, anyway)

Sunday, April 18, 2010

How to create an Excel file programmatically (Part 1)

This was a fairly easy and straight-forward job without requiring any additional APIs. Microsoft Office 2003 was pretty forgiving about Excel file extension that any auto-generated Excel file would be easily accepted without much hiccup. Nowadays, with Office 2007 and the upcoming Office 2010, we again are forced to resort to a "few" different Excel-creation techniques which yielded various pros and cons.

  1. The should've-been-the-easy-way: (X)HTML+CSS+Excel Formula minus-JavaScript format saved as .xls file.
  2. The should've-been-just-as-easy-way: Office 2003 XML format saved as .xls file.
  3. The what-we're-now-forced-to-do: Microsoft OpenXML SDK (2.0) way creating a warning-free Excel 2007 file (SDK 2.0 is the most recent library for Office 2010).

I think I know one of the many reasons Microsoft decided to restrict the flexibility later versions of its Office suite—something to do with all those macro/VBA-infected office files or something like that. So they now go by the "locked-down-by-default" starting point. But I also think it's a crying shame that we get all sort of warning dialogs for file extension renaming and things that are already automatically recognized by Microsoft Office suite, anyway. If only there's a way to suppress the dialog from an administrative policy instead of going to each user's PC... If anything, they should make still automatically protect the end-user while still enabling programmers maintain high-productivity by adopting web document standard but without that whole pop-up dialogs everytime so that worker-bee programmers like myself aren't forced to find, re-devise yet another technique to create, and yet again re-wrap a new set of APIs on a new SDK just to do what's supposed to be a simple thing. Do I digress? Perhaps not. We'll see with the aforementioned techniques in the following illustrations.

(X)HTML && CSS || Excel Formula !JavaScript method

This technique is as simple as it could be; there really is no other additional digging required other than what any web programmer already knows. Anyone could manually write the (X)HTML-based Excel file or use his/her favorite programming language to generate the intended file. You be the judge after seeing the code in Listing 1 below.

<!--xml version="1.0" ...?--> <!--DOCTYPE html PUBLIC "... XHTML 1.0 Strict//EN"... --> <html> <head> <title>XHTML-based Excel file</title> <style>/*CSS styling directives here*/</style> </head> <body> <table> <tr> <td>This is Cell A1 in Excel</td> <td>This is Cell B1 in Excel</td> </tr> <tr> <td>123</td> <td>456</td> <td>=A2+B2</td> </tr> </table> </body> </html>

The advantages of this technique are as apparent as the advantages of following a widely-accepted and standardized document object model, especially one that would be readily usable on a web browser. In addition, this would translate well to the natural order of a spreadsheet being a two-dimensional table understood as rows and columns made up of cells. Those as what

<table>, <tr>, <td> and other related (X)HTML elements are for.

The one great disadvantage stemmed from an annoyance of the application (understandably) warning the user that the content format is different from what is understood by Excel when looking at an .xls file extension. And it is more often than not sufficient to put-off a client-centric programmer who cares about NOT scaring his customer as much as he does about programming ease and efficiency.

Will this image: XHTML-based Excel file warning dialog be enough to make us try to think of a new, more "Excel-worthy" technique? I certainly thought so.

Up next (Part 2): Office 2003 XML format approach.