My struggles in understanding and learning about Object Oriented design, and the tools and knowledge I've taken from them.
Wednesday, February 16, 2011
User Experience
Tim, Hero Extraordinaire
I just completed a massive (well massive for the company I work for, anyway) process of importing some 6 million records into the CRM software we use. It was an arduous process, but the work of one person (me, of course), over the course of about a week, saved a half a dozen people several weeks, or even months of data entry work. It was a major win for both the company and the department I work in.
The Shocker
Because I'm a bit of a narcissist (or maybe even a diligent worker), I took some time to get a pulse check on how some of the end users were feeling about the software transition - of course, I was expecting to get pats on the back, offers of free beer, first-born children, and a lifetime of gratitude. What I got instead was feedback from several people that it had been challenging and frustrating experience for them, even some of those people who were saved all that tedious time of data entry!
Wait a minute. What? What are you talking about? I saved you people zillions of keypresses, and that's your response? That this has been a frustrating process? Don't you people remember the last transition like this that you had to deal with (before I joined the company, of course)? Printouts of data entry items had to be put in garbage bags for queuing because you ran out of boxes!
So, the narcissist (or diligent worker...however you wish to label me) in me felt quite inclined to probe into why this was a frustrating experience.
I got responses like:
...The screen layout isn't quite right
...When I press the tab key, it takes me to a different field than I want it to.
...This screen's background color gives me a headache.
If you've ever built any sizeable pieces of software, you know that these issues raised by the end-users are so mundane, that it's hard to give them priority over the bigger pieces of functionality that need to be built. Background color, control placement, tab index...all of these things often end up being afterthoughts. Finding the right decision tree algorithm, or appropriate layering of your application's architecture are much sexier problems to solve.
But to the end user, they make up a huge element of their experience.
Lessons Learned
I don't really have any pearls of wisdom to provide around this. After all, I'm certainly not an artist, and user interface elements are not particularly a strength of mine. But I did take something important from this process.
Firstly, when you take work away from someone who never knows they were going to have to do that work in the first place, the work you take away from them is invisible to them. They don't care, and neither would you if you were in their position. But that's the burden you bear as a person whose role it is to create and optimize processes that benefit end users.
Secondly, pay attention to the user experience.
I didn't build the CRM the company uses. The things the users mentioned about their experience were all configurations of the software, and after paying attention to what the end-users were saying and changing the settings to what were optimal for them, we ended up getting a lot fewer complaints about this process.
Aftermath
Since the CRM transition, I've pushed out a couple new features in an internal application that the marketing department uses, and for those features, before they got rolled out to production, I spent some time looking over the shoulder of an end-user who was testing it for me. The 20 minutes I spent doing that led me to make a few minor tweaks to the user experience, and ended up saving the user several mouse clicks and about 30 seconds every time they used the features I built. This 30 seconds, multiplied by a few hundred times per year, will be paying dividends for years. And the user will enjoy using the software because it doesn't subconsciously make them want to start the building on fire because of all the darn mouseclicks their main software requires.
Conclusion
There are lots of themes in software development. If we're not busy creating solutions that look for problems, we're spending a lot of time solving problems for ourselves, rather than for the consumers of our products. User experience matters more than we think, and minor tweaks to the user interface help us to "put a bow" on our masterpieces. As software developers, it's important to make sure that we pay attention to the user experience, and find opportunities to decrease mouse clicks, make the user interface more aesthetically pleasing, and create a user interface flow that is intuitive.
I just completed a massive (well massive for the company I work for, anyway) process of importing some 6 million records into the CRM software we use. It was an arduous process, but the work of one person (me, of course), over the course of about a week, saved a half a dozen people several weeks, or even months of data entry work. It was a major win for both the company and the department I work in.
The Shocker
Because I'm a bit of a narcissist (or maybe even a diligent worker), I took some time to get a pulse check on how some of the end users were feeling about the software transition - of course, I was expecting to get pats on the back, offers of free beer, first-born children, and a lifetime of gratitude. What I got instead was feedback from several people that it had been challenging and frustrating experience for them, even some of those people who were saved all that tedious time of data entry!
Wait a minute. What? What are you talking about? I saved you people zillions of keypresses, and that's your response? That this has been a frustrating process? Don't you people remember the last transition like this that you had to deal with (before I joined the company, of course)? Printouts of data entry items had to be put in garbage bags for queuing because you ran out of boxes!
So, the narcissist (or diligent worker...however you wish to label me) in me felt quite inclined to probe into why this was a frustrating experience.
I got responses like:
...The screen layout isn't quite right
...When I press the tab key, it takes me to a different field than I want it to.
...This screen's background color gives me a headache.
If you've ever built any sizeable pieces of software, you know that these issues raised by the end-users are so mundane, that it's hard to give them priority over the bigger pieces of functionality that need to be built. Background color, control placement, tab index...all of these things often end up being afterthoughts. Finding the right decision tree algorithm, or appropriate layering of your application's architecture are much sexier problems to solve.
But to the end user, they make up a huge element of their experience.
Lessons Learned
I don't really have any pearls of wisdom to provide around this. After all, I'm certainly not an artist, and user interface elements are not particularly a strength of mine. But I did take something important from this process.
Firstly, when you take work away from someone who never knows they were going to have to do that work in the first place, the work you take away from them is invisible to them. They don't care, and neither would you if you were in their position. But that's the burden you bear as a person whose role it is to create and optimize processes that benefit end users.
Secondly, pay attention to the user experience.
I didn't build the CRM the company uses. The things the users mentioned about their experience were all configurations of the software, and after paying attention to what the end-users were saying and changing the settings to what were optimal for them, we ended up getting a lot fewer complaints about this process.
Aftermath
Since the CRM transition, I've pushed out a couple new features in an internal application that the marketing department uses, and for those features, before they got rolled out to production, I spent some time looking over the shoulder of an end-user who was testing it for me. The 20 minutes I spent doing that led me to make a few minor tweaks to the user experience, and ended up saving the user several mouse clicks and about 30 seconds every time they used the features I built. This 30 seconds, multiplied by a few hundred times per year, will be paying dividends for years. And the user will enjoy using the software because it doesn't subconsciously make them want to start the building on fire because of all the darn mouseclicks their main software requires.
Conclusion
There are lots of themes in software development. If we're not busy creating solutions that look for problems, we're spending a lot of time solving problems for ourselves, rather than for the consumers of our products. User experience matters more than we think, and minor tweaks to the user interface help us to "put a bow" on our masterpieces. As software developers, it's important to make sure that we pay attention to the user experience, and find opportunities to decrease mouse clicks, make the user interface more aesthetically pleasing, and create a user interface flow that is intuitive.
Tuesday, February 8, 2011
A PHP Data Access Layer that uses Custom DataTable
In my last post about PHP Code that looks like .Net Code, I demonstrated a DataTable object that I built in PHP.
I'm really digging the potential that has bought me, so I created a DataAccessLayer object that has a method that can return query results as a DataTable.
To download the updated "library" I'm building, Click Here.
The method I built is in the class.DataAccessLayer.php file. The contents of the method are below:
So, I could issue the following code to my data access layer, and I would be able to iterate through the results:
So there you have it, a simple data access layer that returns a (somewhat) sophisticated object in a quick, non-obscure way.
I'm really digging the potential that has bought me, so I created a DataAccessLayer object that has a method that can return query results as a DataTable.
To download the updated "library" I'm building, Click Here.
The method I built is in the class.DataAccessLayer.php file. The contents of the method are below:
///Gets the query results as a datatable
public function QueryResultsAsDataTable($query)
{
$this->connectToDatabase();
if( substr($query, 0, 6) == "SELECT" )
{
$currentRow = 0;
if(!strpos($query,"'"))
{
$query = mysql_real_escape_string($query);
}
$this->_dataSet = mysql_query($query, $this->_connection);
$returnDataTable = new DataTable();
if($this->_dataSet)
{
if (mysql_num_rows($this->_dataSet)> 0 && $currentRow == 0)
{
for ($i=0; $i < mysql_num_fields($this->_dataSet); $i++)
$dt->AddColumn(mysql_field_name($this->_dataSet, $i));
}
while($this->row = mysql_fetch_array($this->_dataSet))
{
$dr = $returnDataTable->NewRow();
for( $this->columnCount = 0; $this->columnCount < mysql_num_fields($this->_dataSet); $this->columnCount++ )
{
$columnName = mysql_field_name($this->_dataSet, $this->columnCount);
$dr->AddValue($columnName, $this->row[$this->columnCount]);
}
$returnDataTable->AddRow($dr);
$currentRow++;
}
return $returnDataTable;
}
throw new Exception('Error getting data: ' .mysql_errno($this->_connection) . ': ' . mysql_error($this->_connection));
}
}
So, I could issue the following code to my data access layer, and I would be able to iterate through the results:
$dt = $_dataAccessObject->QueryResultsAsDataTable("SELECT firstname, lastname FROM people WHERE id=3");
$firstName = "";
$lastName = "";
for($i = 0; $i < $dt->Rows->GetCount(); $i++)
{
$firstName = $dt->Rows->GetValue("firstname");
$lastName = $dt->Rows->GetValue("lastname");
print("FirstName is " . $firstName . " - LastName is " . $lastName);
}
So there you have it, a simple data access layer that returns a (somewhat) sophisticated object in a quick, non-obscure way.
Monday, February 7, 2011
PHP Code that Looks like .Net code
This blog references PHP files available for download here: Click Here
In programming, I think it's important to learn. Learning can involve new aspects of your chosen language, or new languages. I've been thinking about my PHP days lately. I really know a lot more about programming now then I did when I was actively programming in PHP.
When I go back and look at some of the code I was producing in PHP, I cringe a bit at all of the principles I see myself violating. Most of the PHP code I wrote were big balls of mud.
So, as an academic experiment, as well as to try to re-sharpen some of my PHP skills, I decided to write some base libraries that I may (or may not) eventually use someday.
As with any language (programming or verbal), or with any foreign concept, the first thing to do is to find metaphors that allow us to relate the themes of the thing we're learning to the things we already know. The classic example in programming is the Hello World application.
Well, I'm not too interested in creating a "Hello World" for PHP, because I'm already familiar with a little bit of how PHP works. But what I wanted to do was to build some PHP code that looks (at least a little bit) like .Net code.
So, after thinking a little bit about what libraries I use most in .Net, I centered around System.Data, in particular DataTable (and DataRow, DataColumn, DataRowCollection, and DataColumnCollection). I haven't created DataSet yet, because there's only so much time in the day.
After thinking a bit more about how I would build some of this PHP code that looks like (has a similar interface) the System.Data .Net library, I concluded that I wanted to have a base Collection object. So I created it, and put it into a file called System.Collections.php. Below is a diagram of the code I created:
As you can see, in my PHP code, a DataTable has a DataRowCollection and a DataColumnCollection, as well as a couple of the external interface behaviors of .Net System.Data.DataTable (NewRow() and AddRow()); however, because of core differences between C# (or I guess .Net languages) and PHP, there are a few changes. Below are the issues that I encountered in this mini-project:
1. I couldn't figure out if I could use an indexer type property to have square brackets ([]) to represent an indexed item in a collection. Therefore, I left that for later.
2. There are some pretty serious differences between C# and PHP in terms of how they type variables. In C#, generally you generally define a variable as a type on the left side of the variable name, and you initialize it on the right side (eg int a = 3; OR Person p = new Person()). You don't have to do that in PHP, so you can initialize a variable as any type, which throws a bit of a wrench into the model of how I see the world.
3. PHP (at least 5.0) supports a lot classic OOP concepts such as inheritance, interfaces, polymorphism, Exception handling, etc. Obviously, the syntax of how to do this is different than it is in C#, so I dealt with some of the pains of the languages' differences.
4. PHP (from my understanding) does not support generic variables. So I can't use List variables the way I like to in C#. So, that's why DataRow and DataRowCollection both inherit from my Collection class.
But, I think my finished product gives me a basis to build on for later. So, if I wanted to initialize a DataTable in PHP code, I would include a reference to System.Data.php, and do something like below:
Notice in the above that, unlike c#, I can't do $dr["FirstName"]. Maybe there's a way to do this in PHP, but in my (short) research time, I didn't find it.
Obviously, this interface isn't exactly the same as .Net's System.Data, but it's close enough to give me a decent metaphor between PHP and C#.
Please note that I haven't tested this code yet, so there are no guarantees as to whether or not it works. If it does work, expect more blog entries on this topic.
To download the PHP Code I've got so far, Click Here
In programming, I think it's important to learn. Learning can involve new aspects of your chosen language, or new languages. I've been thinking about my PHP days lately. I really know a lot more about programming now then I did when I was actively programming in PHP.
When I go back and look at some of the code I was producing in PHP, I cringe a bit at all of the principles I see myself violating. Most of the PHP code I wrote were big balls of mud.
So, as an academic experiment, as well as to try to re-sharpen some of my PHP skills, I decided to write some base libraries that I may (or may not) eventually use someday.
As with any language (programming or verbal), or with any foreign concept, the first thing to do is to find metaphors that allow us to relate the themes of the thing we're learning to the things we already know. The classic example in programming is the Hello World application.
Well, I'm not too interested in creating a "Hello World" for PHP, because I'm already familiar with a little bit of how PHP works. But what I wanted to do was to build some PHP code that looks (at least a little bit) like .Net code.
So, after thinking a little bit about what libraries I use most in .Net, I centered around System.Data, in particular DataTable (and DataRow, DataColumn, DataRowCollection, and DataColumnCollection). I haven't created DataSet yet, because there's only so much time in the day.
After thinking a bit more about how I would build some of this PHP code that looks like (has a similar interface) the System.Data .Net library, I concluded that I wanted to have a base Collection object. So I created it, and put it into a file called System.Collections.php. Below is a diagram of the code I created:
As you can see, in my PHP code, a DataTable has a DataRowCollection and a DataColumnCollection, as well as a couple of the external interface behaviors of .Net System.Data.DataTable (NewRow() and AddRow()); however, because of core differences between C# (or I guess .Net languages) and PHP, there are a few changes. Below are the issues that I encountered in this mini-project:
1. I couldn't figure out if I could use an indexer type property to have square brackets ([]) to represent an indexed item in a collection. Therefore, I left that for later.
2. There are some pretty serious differences between C# and PHP in terms of how they type variables. In C#, generally you generally define a variable as a type on the left side of the variable name, and you initialize it on the right side (eg int a = 3; OR Person p = new Person()). You don't have to do that in PHP, so you can initialize a variable as any type, which throws a bit of a wrench into the model of how I see the world.
3. PHP (at least 5.0) supports a lot classic OOP concepts such as inheritance, interfaces, polymorphism, Exception handling, etc. Obviously, the syntax of how to do this is different than it is in C#, so I dealt with some of the pains of the languages' differences.
4. PHP (from my understanding) does not support generic variables. So I can't use List variables the way I like to in C#. So, that's why DataRow and DataRowCollection both inherit from my Collection class.
But, I think my finished product gives me a basis to build on for later. So, if I wanted to initialize a DataTable in PHP code, I would include a reference to System.Data.php, and do something like below:
include 'System.Data.php';
$dt = new DataTable();
$dt->AddColumn("FirstName");
$dt->AddColumn("LastName");
$dt->AddColumn("Age");
$dr = $dt->NewRow();
$dr->AddValue("FirstName", "Tim");
$dr->AddValue("LastName", "Claason");
$dr->AddValue("Age", 29);
$dt->AddRow($dr);
Notice in the above that, unlike c#, I can't do $dr["FirstName"]. Maybe there's a way to do this in PHP, but in my (short) research time, I didn't find it.
Obviously, this interface isn't exactly the same as .Net's System.Data, but it's close enough to give me a decent metaphor between PHP and C#.
Please note that I haven't tested this code yet, so there are no guarantees as to whether or not it works. If it does work, expect more blog entries on this topic.
To download the PHP Code I've got so far, Click Here
Subscribe to:
Comments (Atom)
Blog Archive
Followers
About Me
Search This Blog
Powered by Blogger.