How has the mobile trend affected you?

In the last few years, one big thing has been popping up in homes and pockets across the world. What is it? A “Smart phone”. If you don’t have an iPhone, then you probably have another “smart device” like any of a number of Android phones, or one of the newer Blackberry’s or maybe a Palm Pre.

The main driving factor for these smart devices in all of our pockets is the need to stay connected. You may think that it is the iPhone that caused it, but even if Apple didn’t release a phone, we would all still have some sort of device. The thing is, most of us do have an iPhone in our pockets, and a percentage of us also have an iPad, but it can’t quite fit into my pocket anyway. Read the rest of this entry »

Facebook, Pandora, YouTube, Stocks, Fandango or TMZ - what’s your favorite iPhone app? Communication has changed greatly with the emergence of the iPhone and the hundreds of applications available. Whether it’s games, music or organization and finance tools, many iPhone users say they can’t live without their apps. It’s a world of unlimited entertainment at your fingertips.

Still just using your voice to communicate? Or is SEND and END the way you are used to communicating while on the go? Let me explain how iPhone apps are changing the way iPhone users communicate and seek information. Read the rest of this entry »

Company’s software serves diverse industries

by April Wilkerson
The Journal Record November 9, 2009

OKLAHOMA CITY – When business doesn’t operate as logically as it should, a local Web and software development company is writing code for a smoother venture.

Oklahoma City-based Phase 2 Interactive has enhanced the daily functions at DrillRight Technology Inc. and S&S Promotions Inc. with software that has a similar effect on two disparate companies.

But it’s far from adding a bit of programming to a snazzy Web design.

“We don’t just sit down and start writing code. The up-front planning is just as important,” said Heath Clinton, president and chief operating officer of Phase 2. “If we do a good job of planning and communicating, the programming comes very easily.” Read the rest of this entry »

Our first iPhone/iPod Touch application, Quadrangle, was approved and released to the iTunes App store yesterday.  Quandrangle is a simple but addictive puzzle game where the player is challenged to find blocks of the same color which form a rectangle.

Colbey Chittenden led the development on the project with game play ideas from Chad Scott and graphic design by Jacob Eck.   The team cranked through the app in about a month, learning the iPhone SDK (Software Development Kit) quickly then building the game in just a few weeks.

For more information about Quadrangle and how to get it on your iPhone or iPod touch click here.

In my previous post I talked about why we have a  Software Bill of Rights and described in detail the first Right.  Let’s talk about the second Right.

1.  Clients have the right to working software, at regular intervals, throughout the implementation life cycle.

2.  Clients have the right to usable software.

3.  Clients have the right to clear, non-technical communication about the software being developed and the development process.

4.  Clients have the right to the best solution available.

5.  Clients have the right to be regularly involved in the software development process.

Good software should work well, but you’ll notice it doesn’t say clients have the right to working software.  “Working” software means different things depending on who you’re talking to at the moment.  To some “working” can mean the software works if you do things just right, if you enter all the correct information, you remember the correct order of operation or you’ve read the instruction manual ten times through.  To others “working” means a piece of software should do everything they can think a user will ever want, everything they can dream up or everything a competitor is doing.

“Usable” means something different and gives us the right foundation.  It implies a balance between over-engineering vs. under-engineering and feature creep vs. under-development.  Usable means the software does everything that it needs to do, nothing more and does so elegantly.

The key to “Usable” is that it puts the focus where it should be, the end user.  While most of the time the client and the developer have great ideas and intentions, neither can be the objective third party necessary to create great software.  By focusing on exactly what end users need inorder to accomplish their tasks we get an unbiased judgement about that button placement, this workflow order or the proper number of navigation elements.

Without fighting for this Right, a project will only be a success for the end user through pure luck.  Watch this video for a hilarious but oh so true example of what happens when you don’t value “Usable”: http://www.youtube.com/watch?v=jVb8EC1Y2xM

What is an Arduino? An Arduino is an all in one programmable microcontroller that allows you to start off very quickly in the world of microcontrollers. It is an Open Source hardware controller and there are many flavors out there, each catering to many different needs.

Arduino has an Integrated Development Environment based on the same environment used in Processing. Arduino can be programmed in the IDE using a language like AVR C that is based on the same language used for Wiring. Today I will show you how to get started on the basic “hello world” of microcontrollers. A page provided by the people who make Arduino’s explains more about what it is and can be found here.

To get started you will need a few things:

• An Arduino board (or most any one of the many clones out there which I will discuss later)
• A compatible computer and OS (OSX Linux and Windows are supported)
• The IDE (downloaded from Arduino.cc)
• An LED (not all clones have a built in LED on pin 13)
• An appropriate resistor for your LED (resistor values can be calculated here more info below)
• A breadboard and some patch cables

Arduino is an open source hardware device which means that it is freely available for people to get the schematics of it and create their own flavor. For this blog, I am using a seeeduino which is an arduino made by SeeedStudio and has a few advantages over the traditional arduino, like extra analog I/O and more surface mount parts which makes for a lower profile. Arduino clones are usually designed for a specific purpose, like the Roboduino which has everything setup so you can plug in PWM cables for motor controls, or the Stickduino which is about the size of a pack of gum but has all the same power as a traditional arduino. Usually, all of these clones can use the IDE for development but sometimes the method of connecting the arduino may be different.

It is the special purpose clones that might not have an LED built in on pin 13 and for this you would need an external LED and resistor to follow along, but if you have one of the many clones that are the same form-factor as the original arduino, you should have an integrated LED somewhere on the board.

If you do not want to use another LED and you have one built into the arduino then you do not need to have a separate LED and resistor or breadboard and patch cables. If you have an LED built in and have a separate LED, resistor, breadboard and patch cables, then you can blink each one individually or at the same time using the same way that I will cover below. Having a breadboard and patches handy is also great for prototyping or just playing and is good to have around anyway. Most places that sell arduino’s will have breadboards, and some will have the male to male patch cables that make it easy to plug and play into the arduino and breadboard. A breadboard is basically like a Printed Circuit Board that you don’t have to solder anything with. It has a bunch of 0.1″ holes that are wired like a typical prototype PCB.

Once you have everything you need, it’s easy to get started. First let’s make sure you have the correct resistor for your LED. Visit led.linear1.org and let’s put in some numbers.

What I have is an LED that has a forward voltage of 1.7v and an output of 20ma so I plug these values into the calculator and it get back a 180ohm resistor. If you happen to have 180ohm resistors laying around, you can use those. The rule is a plus or minus 10% is still ok, And if you go with higher ohms it will just mean less power gets to the LED. So in my case, I have a 220 ohm resistor sitting here so I will use that since it is higher than what is recommended and will not burn out the LED but still allow enough power to get to the LED to light it up.

Now we need to setup everything. If you are using the integrated LED then you are ready to go and can skip to the code section. For the external LED you will need to plug some things into your breadboard. First, let’s plug in the LED. I have mine put against the middle rail so I have plenty of access to the power and ground rails if i need to use them. And so I can put things in front of it, namely things that will come off the breadboard and connect to the arduino itself.

Next I will plug in my resistor to two spots on the breadboard, but one of those spots will be one of the lanes that a leg of the LED is plugged into. This is so we can make sure the power goes through the resistor at some point on its way through the LED. You can select either leg of the LED to connect the resistor, just so it is on one and only one of the legs. Otherwise we will not actually be limiting power.

Now we will plug in our power and ground into our breadboard. We will need to know which leg of the LED is the anode (+ or power) and which is the cathode (- or ground). The anode is usually the longer leg of the LED, also on some round LED’s the cathode side is flat on the body. For my setup, I will be putting the resistor on the cathode, for no specific reason. Now I will plug the supply wire into the lane the anode is on and I will plug in the ground wire to the lane the resistor is plugged into and the LED is NOT plugged into.

Now we can plug in the wires to the arduino. I will use the GND pin just past pin 13 on the right side of the Arduino and plug in the supply line to the digital pin 3 marked with a PWM on it. The integrated LED is usually connected to pin 13 and we will utilize that when we get to coding.

Next go to your computer and open the arduino IDE. I am using version 0015 which is current as of this writing. In the IDE, navigate to File > Sketchbook > Examples > Digital and select Blink. This will open up the blink “sketch” so we can upload it to our arduino. In the arduino IDE, a “sketch” is what we call the program that will be uploaded to the arduino. Next plug your USB cable into the arduino and then the computer so it can be found by the IDE. Once we have it found, we will need to setup the IDE to connect to it. Click Tools > Board and select the arduino you are using. Diecimila should be good if you do not know or have a standard arduino. Next click again on Tools > Serial Port and select the serial port that is created by the software on the arduino. If you do not know then you can unplug the arduino and click on Tools > Serial Port and see what is there, then plug it back in and click on Tools > Arduino and select the new one that shows up. Once everything is setup, your IDE should look something like this:

With the arduino plugged in and the IDE ready to go, we can upload the sketch. This is done by clicking the “Upload to I/O board” button or going to File > Upload to I/O Board or you can use the keyboard shortcut, which differs based on your operating system. What this will do is compile the sketch and then upload the compiled version to the arduino. Once there, you should see the LED on your arduino blink. But, if you do not have an LED integrated, your board might just look like it does when it is not plugged in. To solve this, we will change a little bit of the code.

First lets talk a little bit about what the code does:

int ledPin = 13;

this just sets up a variable to make it easier for us to know later in the code, which pin is the LED pin.

pinMode(ledPin, OUTPUT);

This is how we tell the arduino that we are going to be writing to “ledPin” rather than reading from it.

digitalWrite(ledPin, HIGH);

This is how we actually write to the “ledPin” and control the LED. Note that this line is used twice, once it sets HIGH and once LOW. Basically it is saying HIGH sends power (5v) to the pin or you can think of it as turns it on. Sending LOW sets the power to 0v, or turns it off. HIGH and LOW are reserved words for the IDE and do not have to be defined.

delay(1000);

this tells the arduino that it needs to wait 1000 milliseconds, or 1 second, before going on.

Now we need to add code to make our external LED turn on. Lets first define a pin so we don’t have to use just the number later in the code. Under the “int ledPin = 13;” line lets add a new int and call it something useful like redLedPin and set it to our pin number, which should be 3. It will be the pin number you plugged the supply wire into. Next, we need to set our pin to output, so under the current pinMode call, lets add one that sets our new redLedPin to output. Now we are ready to make the LED turn on and off however we want. I am going to make my redLedPin turn on when the other LED is off. So now my code looks like this:

We can upload our code to the arduino and test it out. On my setup, I have pin 13 turning off when pin 3 turns on, and pin 13 turns on when pin 3 turns off. That is just the beginning. Now you can add all sorts of stuff to your code, or to your breadboard and have all sorts of fun. Some examples may be adding a button to make the LED’s turn on, or adding a potentiometer to adjust the fading of the LED. But the possibilities go on and on and on. Comment or email if you have questions.

In my previous posts I discussed the way Phase 2 develops a deep understanding of our clients’ needs. Once we discover the needs and can fluently speak in the language of measures of success, we create a technology implementation plan. In the next series of posts I’ll cover my philosophies around the process of implementing a custom software project, we call it a Software Bill of Rights, credit to Jeff Palermo for articulating it as such. It’s what every client should expect from us, or any software partner.

There are 5 Rights our clients can expect during the implementation cycle of a project with P2.  While the details of an implementation will change depending on the project and the team, these are the guiding principals.

1.  Clients have the right to working software, at regular intervals, throughout the implementation life cycle.

2.  Clients have the right to usable software.

3.  Clients have the right to clear, non-technical communication about the software being developed and the development process.

4.  Clients have the right to the best solution available.

5.  Clients have the right to be regularly involved in the software development process.

Let’s talk about Right #1: “Clients have the right to working software, at regular intervals, throughout the implementation life cycle.”  I’ll make this bold statement, it is impossible to create an effective, well designed piece of software on the first pass.  Iterations are necessary and great software can only be created through iterations of actually working code and interfaces.  To meet the ultimate vision, a development project requires that the end user get their hands on the software as early and as often as possible.

There are no practical amounts of upfront specifications that will allow a development team to get a software compenent correct the first time.  Clients will forget things they needed, developers will botch routings they shouldn’t have, etc.  This first Right in the Software Bill of Rights defines the essential need for the end user to have access to working components of a piece of software throughout the develoment process.  This creates a fundamental feedback loop between the client and the developer.  Feedback is absolutely necessary for both the client, as they will gain confidence in code they cannot see, and the developers, as they will be able to craft the solution based on user interaction.  It is always a bad idea to take a software spec, have developers go build from it for a month or two, then show the results to the client.

Feedback should happen at least once a week with real working components that the client can touch.  This means developers must be mindful of error handling, bugs and UI issues at all stages of development.  Usable software early in the cycle helps keep the software on the right track, meeting the client’s needs and expectations, as well as allowing a developer to implement creative concepts which are difficult to justify without the client seeing them actually work.

As with all rights, these involve a high level of responsibility; great software implementations require a commitment to this feedback loop from both the client and the developers.  Clients must be committed to the, often substantial, time to use and test the ever changing prototype, giving valuable feedback to the development team.  Developers must be committed to the process of creating incremental, usable pieces of software, which requires a constant committment to working components at all stages, consistent focus and a willingness make user feedback a primary value.

In the end this Right facilitates great, usable software and happy clients.

As I discussed in my previous post, when we start a project at Phase 2, we always start by looking at the people involved. We look at the different constituents, both internal and external to the organization, what each wants and needs as well as the current problems each face. After we understand what particular groups of people are looking for, we ask the tough but essential business question: If the goals are met and the problems are solved, how does it positively affect the organization’s bottom line and/or mission? What is the measurable success the business will see upon the successful implementation of the software system? This question is so essential to a successful software project it sends my stomach in knots when I think about how often it doesn’t even get discussed. It’s easy, especially for technologists, to fall to the temptation of justifying software just because it’s cool, it seems needed or someone else is using it. It is equally tempting for businesses to reject software recommendations because it seems too expensive, too new or because the benefits aren’t clear. Technologically impressive but ineffective software doesn’t make for good business partnerships but, neither does unimaginative software that misses opportunities for real innovation. In our information age, businesses large and small need great software partners to survive.

The only way to manage a great partnership is to create win/win situations, which is patently impossible if there is not a deep understanding of how each component in a software project will impact the bottom line success of an organization. Clear measures of success, or MOS, provide a common language between a business and their software development partner, help to justify innovation and facilitate long-term relationships by providing quantifiable return on investment.

Creating common language is often difficult between business partners, but is particularly challenging between businesses and their software partners. The intangible nature of software and the obscurity about how it’s created adds tremendous difficulty to the communication. Here’s a real life example: We developed an application for a directional drilling company that helps them manage their drilling process. During the life cycle of the project we discovered that a single job could have multiple drilling paths or tracks instead of just one. This seems like and easy fix, just add another track, but to make the change required substantial revisions to the software. Conversely, things that seem difficult are often easy. On a different project we were asked to add a seemingly complex calculation to a list of items. While this seemed complex to the client it was actually rather easy to implement. Similar situations happen on nearly every software project. In most cases the obscurity of how software works creates a large communication and understanding barrier between a business and its software partner. The common language of Measures Of Success is the key to overcoming this barrier. If we frame our above examples in the language of MOS it will look more like this: obscure software situation A will cost X dollars and benefit the organization in Y ways. That’s an easy decision of any businessperson to make.

The MOS language also allows software developers to justify key, high impact innovations. Smarter, faster, more usable, more elegant, etc. are usually expensive, often prohibitively so for many businesses. Software that is 85% of the way to what a business is looking for but 200% cheaper is normally good enough to go with. The problem is that most software developers are artists at heart; we are in the business to add new and innovative solutions to the world. Getting 85% of the way to an elegant solution is disheartening and all to often we are right to feel discouraged. While an 85% solution based on a budget may run the business just fine, that budget is more often then not, built without a technology imagination that envisions the impact of innovation. Great software partners live in a world shaped by the results of innovations, we are often first movers and adopters of technology that actually changes how we play, work, communicate and even think. 85% doesn’t change the world and we understand this intimately. Fluently speaking the language of MOS allows a developer to help a business owner imagine and then calculate the impact real, but perhaps seemingly expensive, innovations will have on his/her business. This gives software developers the opportunity to create real innovation for their clients.

Finally, speaking MOS brings the opportunity to strengthen the partnership by creating a structure which creates a clear picture of the return on investment of a software project or component. The quickest way for a relationship to turn sour is when one partner or the other perceives real or imagined inequity. A partnership with a software company deteriorates quickly when a project is near to or over budget and there was no clear expectation of the ROI for the project or the components. While 20% over budget on a highly valuable component of a project isn’t critical, that same 20% over budget on a feature that will have little impact on the business becomes a big problem. Without a clear statement about the return on investment of each component in a project it is impossible to make these critical decisions until it’s too late and the relationship is in trouble. Measurable success allows ROI to easily be defined before a line of code is written, making it clear how to prioritize a project.

Defining and fluently speaking the language of MOS is critical to a successful software project and in developing long-term partnerships between a business and a software development partner. It’s one of our required steps and has been a key to our success in the very difficult business of improving our clients’ businesses.

At Phase 2, our mission is to improve our client’s business through web based software. Here’s one example of how we have done this recently:

Drill Right Technology – Drill Right Technology is one of the top directional drilling companies in the region. Early in 2008 they identified a need to improve their business processes using technology tools across their drilling operations. Working closely with key personnel we created a software solution that would help them accomplish their goals and solve some nagging issues. Using a variety of cutting edge technologies including Microsoft’s Windows Presentation Foundation (WPF) framework, we built a world class software solution that :

• A top of the line User Interface and intuitive User Experience - Our excellent UI/UX team used the power of the WPF framework to craft a software experience unmatched in the Energy Industry.
• Synchronization of data from operations across various field locations to central data store - The ruggedness of the oil field does not provide the luxury of reliable internet connections, so we developed a partially connected desktop application that allows uninterrupted productivity with all the benefits of an online application when a connection is available.
• Advanced three dimensional drilling predictions – Drill Right needed their field operators to have access to the same advanced well path mapping capabilities as engineers using other costly software tools. By quickly understanding the complex three dimensional well path calculations our team was able to build in well path prediction software that allows field operators to react, in real time, to dynamics of a directional drilling operation.

Yukon Public Schools – Yukon Public Schools began the 2008- 2009 school year by rolling out their newly designed Web site. YPS came to Phase 2 with a set of goals that needed to be met by their Web presence. Not only should the site be a place to find the school phone numbers, but it should become a central hub of information for parents, students, faculty, and the community. To accomplish this, the site would have to be easily maintained with a content management system (CMS) but more importantly, feel organized and attractive. Using a number of solutions and tools within the CMS, we built a Website that:

• Provides clear & well organized navigation
• Is easily updated and maintained by administration and teachers, therefore, providing the Web site with fresh and relevant information at all times.
• Provides easy access to user specific groups such as parents, students, staff, and the community.
• Has an up-to-date attractive feel.

These are only two examples of recent projects where we’ve been able to help our clients improve their core business, in substantial ways, with well designed software.

I believe it is important to have a philosophy when approaching problems in all areas of life. In fact, whether it is clearly stated or not, we all approach life’s different problems with some philosophy. Over the years I’ve spent a good deal of time defining, ripping up and then redefining my philosophy of software development. In next few articles I’ll share with you the Phase 2 approach and why we’ve had such success as a result.

Software development, especially custom business software is at once exciting and extremely difficult. Two companies are never the same and so their software needs are never the same. The technology stack I would implement for two separate companies, even in the same industry could be entirely different. This makes creating a solution difficult, though probably not in the way you would think. The software part of software development is, really, fairly easy. Although, I am spoiled by being surrounded by a group of some of the smartest and most talented people I’ve met, writing code to solve a well-defined problem may take a bit of time, but it’s straightforward. The biggest challenge with software development is you and I.

Designing something that is easy for a human to use is difficult.  As a general rule, a device or piece of software that’s easy to use is the result of the design team having remarkable clarity in their understanding of their audience and of putting in a tremendous amount of hours.  In his book The Design of Everyday Things, Donald A. Norman describes design as a process of communication.  Well developed software is a process of creating something that effectively communicates with humans, how we think, and how we work.

My approach to software is that it’s simply a tool to empower humans, like a very sophisticated hammer humans use to do increasingly sophisticated things. Like a hammer, software should enhance the way people work. If your standard hammer didn’t have a handle it wouldn’t be useful. Software must not only be useful it must always be empowering, it should help us work, think, learn, communicate faster, smarter, better. It must be people centric.

When I say people centric, the first thing many think is that the software should have a good user interface, meaning it should be easy to use.  That’s right, but it’s much more than that. Taking our hammer example, a handless hammer has a rather poor user interface, and does little to empower us.  Go a bit further and we start talking about user experience. A hammer could have a brilliantly designed handle but weigh 100lbs. It’s going provide a rather poor user experience when you have a thousand nails to drive.

A brilliant user interface and intuitive user experience is still not enough.  To get elegant and meaningful people centric software design we have to start at a more fundamental level. People centric software design has to start by helping people achieve their goals and solve their problems. If I’m building a fence with screws, a perfectly designed hammer is still worthless for the task at hand.  The critical first step to successful software is developing a deep working knowledge of the wants, needs, goals and problems of the people involved. This is the heart of people centric software design. Good software enhances humans; it must solve human issues and improve human activities.

The Phase 2 mission is to improve our client’s business through software solutions; the only way to do that is by empowering the people in an organization with people centric software solutions. This is the key to success in the face of all the challenges of software development, the required first step in P2’s development process and the foundation of my philosophy on software development.