February 2010 – Jason Lotito

What I know about designing credit card forms

Credit card forms are pretty simple to make when you first think about it. For many online stores, you plug yourself into PayPal and your done. For other people, you plug your shopping cart into your processor, and you accept the defaults. Maybe someone comes along and adds a custom design, rearranging things a bit, but overall, they don’t change much. After all, the checkout process is pretty simple. It’s set in stone. A credit card form is simple. People are used to it, they know what to enter. Credit card forms are simple, common place, and boring.

Checkout my credit card form

The truth is, credit card forms are far from common place, they are far from simple, and while you might consider them boring, a checkout process, and by it’s nature, the credit card entry form, can actually be very, very interesting. I should know. I’ve spent the last 8 years working with them, and every step of the way, I’ve attempted to learn more about how to make them as easy as possible. With that much experience, let me make something clear: the credit card page is the do or die page. It’s the page where a user will either make a purchase, or fail. Your job is to get make it as easy as possible to make that transaction. Every error you present to the user is another chance that user will decide it’s not worth his time and energy to make a purchase at your site.

Too many sites make the credit card form just another form. They provide basic error checking, but let’s be honest, the credit card form is where everything matters. Capture that information, and you can make money. Fail, and you can’t process anything. It doesn’t matter what you do. So much effort is put into the shopping cart, in shopping, in the front page, in the privacy settings, in the product pages, in everything else we do. But at the end of the shopping cart experience, or when the user is about to make a membership purchase, the credit card page is all that stands before them and the final purchase. You want that person to make that purchase. It’s the only way you can get paid.

Don’t believe me? How many people get to your purchase page and bail out? How many get there, get some sort of error, and fail to finish the transaction? What is your most common error? Do you email the user after failing to submit a credit card? How long does it take to complete your checkout or purchase process? How many attempts does a user make before making a successful transaction? How many do they make before not attempting? How many failed transactions do users make if they don’t make any errors?

These are all questions that are important to online retailers. These all provide vital clues in how people are making purchases online. However, I don’t think people put too much weight into looking at numbers like this. After all, what’s so important about how long it takes to complete a purchase?

Time is vital.

Time allows the person to second guess their purchase. It allows for other things to distract the user from making the purchase. Take too long, make the process too cumbersome, and the might not make the transaction at all. Numbers are important here. Find out how long the average user takes to complete a purchase after they start the checkout process. From start to completion. Getting this information lets you know how fast or how slow your form is. Speeding up the process will increase sales. Cutting even a minute off the purchase means the user has less time to decide against the purchase. He makes the purchase, and it’s done, and he’s happy. No more questions, no more concerns.

What about errors?

Common errors are a problem. Common errors are a failure on your part to correct mistakes for the user. Should your users suffer because of a typo? But what kind of common errors could you fix?

Phone numbers. Phone numbers are a major problem. When I was developing my credit card processing system, we were doing telephone authentication long before PayPal and others got on board. The problem is, on a world wide scale, making sure phone numbers are correct can be difficult. After all, we had a single call center making all the calls at the time, so the calls were made from the New York area. Now, for Americans, it was pretty simple to make sure the phone number was correct. However, most people over in Europe or other parts of the world weren’t entering in phone numbers that could be used to call them from New York. They were entering local numbers. I remember spending some long hours reading up on phone numbers and creating a system that would automatically fix their phone numbers, entering in proper country codes, recoding them if necessary, and basically modifying the number they entered to ensure that we could make the call.

Sure, I could have thrown an error and told them they had to enter the phone number correctly. In some ways I did them. I had some helpful information providing country codes in a nice little pop-up window. But since I had the information anyways, I could just automate the fix for them.

Emails were another issue. user@examplecom is not a valid email address, but user@example.com is. It wasn’t uncommon that I would get com without the dot, and fixing that proved to be helpful.

Keep in mind that each of these errors were, at some point, errors that stopped a user from purchasing. Often times they weren’t the only error, but they were an error.

A really easy fix was removing the credit card type selection. This was done early on. After all, I could easily figure out the type of card by the credit card number entered. Selecting the card was useless for me. It was an extra step I forced upon the user. Even worse was when the user would enter in one credit card number and not change the credit card type.

Asking for the credit card name was another problem. It might seem simple that you ask for the name on the credit card, but you’d be surprised at the number of places that require a first and last name. Even worse, some gateways would request the first name and last name rather than as a whole name, while others wanted the full name on the card. The quick and easy solution is to ask for the first name and last name, and combine them as needed. The problem here is the user needs to enter in his middle name, or middle initial. Even worse is that with two fields, the person will probably have to click his mouse into the next field, taking even more time to fill in the form. Sure, tabbing works, but users usually don’t tab through a form. But why even force them to tab?

One field: Name. If you need to split the first and last name, simply split it along the space. If they enter in a middle initial or a middle name, you can detect that and store it as needed. Essentially, you are given more information to work with, and can still provide all the needed information.

The CVV2 is another major problem, though thankfully people are used to it by now. However, it’s still something people need to enter. I found that letting people know about this number and where to find it was best done based on the type of credit card they were entering as well as providing multiple locations to show where the number was.

First, I’d have a little image, about the size of the text box itself, next to the input box, that showed a small credit card with a little circle where the number was. I also had a nice little “What is this?” link next to that. The user could click, and a small pop-up would appear beside the input area. The image was different depending on the type of card, and we tired our best to pin-point where the number could be found. Some cards have 4 digits followed by 3 digits. The 3 digits are in fact the CVV2 or security code, but the previous 4 are part of the credit card number. Usually the last 4 numbers. Sometimes a user would try to enter those 4 numbers along with the other 3. We had set our CVV2 space to a maximum length, but eventually noticed the problem. We allowed the user to enter in more numbers, and just made sure to remove the numbers we didn’t need. Again, why bother the user with providing us with 100% accurate information. If they give use more than we need, we can always strip out the excess.

Email first

While not directly related to the credit card, the email address is something every online e-commerce system is going to collect. Without a doubt, it’s the way to communicate. What I’m about to suggest might be something that some people might consider to be underhanded, but used correctly, it can provide value to your customers, increase sales, and help solve problems you might know ever existed.

I’m talking about moving the email address up to top of the form. Make it the first piece of information that is requested. As soon as the user finishes entering his email address and moves on, a quick ajax call to the back-end stores the email address next to the purchase information. This is where it can get shady. You don’t want to spam the user, but you do want to assist the user in getting what they want. If the user fails his purchase for whatever reason however, you know have a means by which to follow up with that user. Even if the purchase isn’t successful because the form is never submitted successfully. Let’s say even if the user starts to fill out a form, and then stops half-way through for whatever reason, you now have a means to follow up.

One thing you can do is provide the user with an incentive to complete the purchase. Emailing the customer with a different price let us capture even more purchases than previously. Knocking off 20-30% of the price helped encourage the user to come back and complete the purchase. We were also able to use the time the user was going to make the transaction as an indication of when the user was available. I felt it was safe to assume that if the user was browsing at 3 PM and was going to make a purchase, emailing him the next day around the same time asking if everything was okay wasn’t a bad idea.

What do you really need

Credit card forms are simply complex beasts. They are where you either make money or you don’t. While it might not appear that any of these suggestion alone will seriously increase your profits, together, and over time, they will help. Of course, this requires you to keep track. Every transaction, every error, every piece of data. Knowing what people do, how people use it, what information they get wrong, what information they are entering, all of this is vital. You might be surprised at how many little improvements you can make that, in the long run, help increase how much money you make.

To figure out what you need to do, you really need to track everything. Once you fix the problems, you need to track the places where the transaction would have failed if you hadn’t made the changes you did. This is good because it not only provides you with a direct view into what you are doing right, but it also makes you feel good.

With all that said, this is just the tip of the ice berg when it comes to designing and developing for e-commerce systems. But I really think these are the fundamentals. If you aren’t tracking, if you aren’t correcting, if you aren’t taking the basic steps now, you can’t move forward.

What we can learn about privacy from Google's Buzz fiasco

If your not a regular internet user, you might not be aware that Google’s Buzz has sparked a lot of criticism regarding it’s privacy policies. Basically, the problems weren’t as bad as everyone made it seem, and privacy settings were in place to prevent everything that came up. In many cases, the claims were simply not true, or the issues weren’t exactly as described. In the case of one blogger, they were partly right and Google did fix a display bug, but even in that case, the private information wasn’t disclosed.

But this post isn’t about any of that. Enough has been written about this, and frankly, everything I’ve read has amounted to nothing more than repeating was has already been said, and we haven’t moved toward learning anything from this incident. That is what this post is about: learning.

Privacy: What is it good for?

I use my private Gmail account to email my boyfriend and my mother.

There’s a BIG drop-off between them and my other “most frequent” contacts.

You know who my third most frequent contact is?

My abusive ex-husband.

Which is why it’s SO EXCITING, Google, that you AUTOMATICALLY allowed all my most frequent contacts access to my Reader, including all the comments I’ve made on Reader items, usually shared with my boyfriend, who I had NO REASON to hide my current location or workplace from, and never did.

First, let’s make it clear that Google didn’t allow people access to her reader. This was merely a display error that showed that certain people had access, but really didn’t. But, this post is probably the greatest argument against “If you aren’t doing anything illegal, why do you need privacy?” It’s a real life answer that has real life implications, and shows why it’s important to consider what we can learn from this.

Privacy is also important at a business level. My actions, my privacy, the data I create, are mine, and I have a certain right to them. Sure, I use Google, and I accept that they track my movement online. The price I require Google pay is a good service. It knows me, so it can innovate and create new features in search and other areas that work from that history. If Google ceases to pay that price, I can always stop providing my goods, that is, stop giving them more information to use. There are numerous ways to do this, and it devalues Google a little if I remove information from their system. After all, without that information, they can’t provide services to other people. Indeed, that’s show search engines work. They provide a service as a payment for using your information. When their service isn’t valued, you remove your information from their system, devaluing their service.

But this presents why privacy is important even beyond just a right. My actions, my content, the data I create, are mine. An email I write, a blog post I create is mine, and I have the right in many ways to control the use of the product. Google doesn’t have to provide it’s search service to mine. It doesn’t have to direct traffic to my post. I would lose that payment, but as the content creator, that is in many ways my choice more than Google’s.

The simple fact is, for many people, providing Google with data allows Google to do a better job at providing their services, and we value that service at a certain level. A level where we have no issue with sharing our data to a certain extent.

That’s the business side of privacy. It’s our data, and we have a right to control it.

Who controls privacy

Computers suck at intent. Inferring privacy preferences for new software, based on prior actions in old software, is a recipe for failure, and a PR nightmare. People assume computers are great at intent. We publish things to much wider contexts than we intend, and don’t notice or care until new products and features make incorrect inferences based on that. – On Privacy (or: what Buzz failed to learn from Newsfeed)

This is probably one of my favorite quotes that came out of this incident. More precisely, “Computers suck at intent.” The other side of the coin for me is this: “People assume computers are great at intent.” A great example of the later is the Facebook Login fiasco. People make the assumption that the computer works the way the think it should work. They think computers understand their intent. This is obviously not true, to a point. Google does go a long way toward trying to understand the intent of the user. All that data they collect is directly related toward enhancing aspects of their business: search and advertising. If they can better understand users and use that data to deliver that user relevant search data, they can also use that data to enhance the ads they show. And the ads they show are in many ways geared toward helping us. Their is a fine balance between an ad that adds value and an ad that is just plain annoying. However, a search engine is nothing more than a giant advertising engine. The difference between search results and ads is merely that ads are paid for with money. Search results are paid for in different ways, as described above. It’s another case of give and take. You give Google the ability to search your site, categorize it, and use it to better provide users with what they are looking for, and for that you are rewarded with more visitors from Google. But we’ve already discussed this.

The Facebook Login fiasco demonstrates the value that Google provides, and the strong case that people really do thing computers understand intent. But Google Buzz also shows us that computers can’t understand intent. The second sentence of that quote explains succinctly: “Inferring privacy preferences for new software, based on prior actions in old software, is a recipe for failure.” Now, I don’t think this directly relates to Buzz (I think Buzz was seen by Google more as a new feature of Gmail rather than a new product like Docs or Reader), but it still relates in some ways. But it’s also essential to understand this because it all relates to who controls privacy settings.

Now, it’s easy to say you should be the one to control your privacy settings. But what Buzz taught us is that most people don’t. They assume the computer is controlling it for them, and that the computer understands the intent of the user. Computers don’t. This is why Buzz relied on existing privacy settings. Settings people were not aware of.

On a slight side note, I’ve been using Profiles for a while now, and I had made myself aware of the settings. I made the assumption that most other people would utilize the tools if they weren’t happy with the defaults, and anything concerned at all about privacy would take the time to make themselves aware. On that last part, I was wrong.

So, who controlled privacy? I could argue that the individual should have been more diligent about their privacy and looked into this sooner. The fact is, a lot of people were very much unaware of the tools available and were scrambling at the last minute. Settings that were obvious to many of us who took the time when the tools were provided were shocked that settings that had been in the same place for years were suddenly proclaimed to be hidden. It’s as if suddenly the populace of self-proclaimed privacy-aware individuals suddenly realized that they had to make privacy changes, rushed to the website, and scanned quickly for the big flashing “Privacy Settings” link. When they couldn’t find it within the first few seconds, they proclaimed loudly that Google was hiding these things from them. Hiding settings that have been available for a long time.

But I digress.

Anyways, the ability to control all of this was in the users’ hands, and I could argue they elected to not use the tools provided.

But, I could also argue the opposite side of things. Google clearly didn’t make important parts of this new feature clear enough. Lots of people had concerns, and suddenly, without warning, a cry of alarm sounded. Doing things without explicit permission is dangerous. Sure, Google might be relying on privacy settings that the user agreed to by using the service, but most likely, these were the default settings that the user never really looked at. Surely Google must realize that a default setting is really Google making the choice and not the user? If someone never viewed their privacy settings, if someone never said “Yes, I want to use these privacy settings” explicitly, is this really a choice?

Yes, it’s a choice because the user accepted the default settings.

No, it’s not because the user never explicitly agreed to settings they weren’t explicitly aware of.

Google was right in using the default settings. What other settings could it use? The users used the service, accepted the settings by default. Should Google not use these settings? Should they make up new settings?

Google was wrong because the default settings were given additional meaning. Not new meaning, but the average user couldn’t apply the new features, the new explanations, and keep in mind the new issues that might arise.

Let me explain that last part there. Google Profiles could be made private. Google Buzz followers would be displayed on your profile. Contacts could be automatically followed to your Buzz. In the context of the Buzz situation, is it easy to follow that your contacts might be display on your profile for the world to see? No, not really. Is anything inherently wrong? No, not really. Google is merely display what amounts to what Twitter and numerous other services already do. They are following the status-quo. The implications aren’t immediately apparent.

At the same time, you have all these informants and what not who emailed journalists from emails that could be traced back to themselves. The journalists apparently stored these people as contacts in such a way that made them traceable. These people who wished to remain anonymous were no longer in control of their privacy. They allowed their privacy to leave their control. This isn’t even a Google thing. It’s a control thing. The more private information you give away, or the more often you give it, the less chance it will remain private. And the less control you have over it. This is important, because the problem here has to do with privacy policies we set for ourselves. The informant allows the email they use to be traced back to them. The journalist allows information to be traced back to the informant by storing it. The informant allows his private information into the hands of someone who’s privacy concerns are shared, but not enforced.

Concerning ourselves with our privacy is a right, but like all rights, we have to exercise this right.

What to do with all of this

So far I’ve typed a lot, but I don’t think I’ve said much. Here is where I hope I will make up for the length of this post.

Privacy settings should be explicitly defined, accepted, even if just accepted as defaults.

The problem with this approach is the “Next, Next, Next” syndrome. People click right past it. Already privacy policies are displayed, but rarely read. Privacy settings displayed will just be seen as another hoop to get through. If privacy settings change, logging into the service will be a nightmare. After all, I don’t want to concern myself with saying “Yes, I Accept” to every new change. It also doesn’t solve the problem of finding the privacy settings once they are set. After all, using the service might make you realize you want to set the privacy settings differently. But do we really want an obtuse UI that asks our permission to do everything little thing?

After all, most people are willing to accept some lack of privacy control for ease of use.

On signing up for a new service, or agreeing to a new feature, it would be nice to see these policies and allow me to review them, but I also feel it’s somewhat counter-intuitive to ask the same questions over and over again. But at the outset, the initial launch of a new piece of software, a review of policies and how they apply to the new feature should be made easy to get to. Don’t clutter the UI, but allow me to review the policies that are needed.

Design an interface that is removed from the website

This is the big idea here. We already do something like this for SSL certificates. Browsers display this information to the user in way that they hope is easy to use. Phishing sites and other dangerous sites are also monitored, and users are protected from those sites by browser makers. It’s a real problem. Privacy concerns are also something that is a major concern, but privacy on a site-by-site basis. There is no standard, but this shouldn’t be that hard to correct. After all, RSS feeds are already supported by browsers. Why not take this a step further and support Privacy URLs. This would be the location the site proclaims as their “Privacy Center.”

I propose two types of links:

<link rel="privacy_policy" href="http://www.example.com/Privacy/Policy">
<link rel="privacy_settings" href="http://www.example.com/Privacy/Settings">

Using these like you would RSS feeds, you allow the browser makers to create buttons, widgets, or whatever to allow the user browser based control to go immediately to the privacy policy and settings for a website. Just like an SSL certificate, it gives the users a way to avoid dealing with a sites design. It also allows the software developer the knowledge that even if user misses the information on the site, they’ve given the user a default way to access privacy settings.

Essentially, this is a common, default way to access something that is rather important. This can be further used by allowing sites to change privacy settings by simply changing the URL they use in the header, and this would notify the browser that the site itself has changed the policy, and can then alert users. This alleviates the developers from coming up with numerous ways to make sure their settings are noticed. They should still allow access via the website by normal means, but it also provides them with additional tools. In a way, it would also make users more aware of privacy settings they might not have otherwise taken the time to explore.

Going this route, I believe we solve a number of the problems.

First, we have a common way of notifying users, alongside other traditional ways. A big problem with Buzz was not finding the settings. The location, while not necessarily hidden, wasn’t obvious. A simple browser button or UI feature would allow us to worry less about finding this information, and deal instead with acting on the information.

Secondly, having these settings in place allow easily review of these settings at any time. We know that we are at the right place, the place that contains all the privacy settings, or the privacy setting center of the site. This is the right location. We aren’t guessing if we are in the correct place. This was another issue with the Buzz roll out.

Finally, this allows companies to update privacy policies and privacy settings in a much more efficient and simple manner. Updated and new settings can be alerted to the user, and the user has an easy place to review these new settings, and it’s within an appropriate context.

Combined with the first step, this would essentially make privacy as important as other features people find important in browsers. Browsers are, after all, the vehicle by which we surf the internet, and this idea, I think, is sort of like your seat belt, something you put in place before an accident happens.

.htaccess SetEnv Conditionals: mod_setenvif

The mod_setenvif module allows you to set environment variables according to whether different aspects of the request match regular expressions you specify.

via mod_setenvif – Apache HTTP Server.

I’ve never claimed to be a server guru, and I’ve never had much interest in delving into Apache configuration files, but web programming almost request that I dig down and learn about what I’m using in order to make the best use of the technologies I’m using. Besides, I’m well past the point where I can keep making excuses for not learning Apache.

Zend Framework 1.10 uses the .htaccess file to set the enviromental variable APPLICATION_ENV. It does this using SetEnv.

SetEnv APPLICATION_ENV production

This let’s us set the environment to production or development, obviously. The idea is that you can set the variable depending on where the files are: a production server or a development server.

However, I wanted something a bit simpler at the moment. I wanted to the variable based on the URL used. beta.example.com would get the development site, and http://www.example.com would load up the production site. Both sites share the same directory as their web directory, but I want the live site to display a ‘Coming soon…” message, while the beta site would let me work. I’m not concerned with people getting access to beta, and the only difference will be the display of the default page, but it’s a simple thing. Now, I could have done this in PHP, but I didn’t want to do this. At the same time, I had in mind the ability to use this setting of environmental variables something I could use for other things, like debugging, web services, and what not. Being able to let Apache handle this, and then letting Zend build the configuration based on this setting, would let me not worry about programing any of this logic into my system. I just program away, and I can make the assumption that whatever happens based on the URL will happen appropriately.

Anyways, a quick check of the docs for SetEnv lead me to discover SetEnvIf. I’ve seen this before, but I never paid much attention to this setting. It’s rather simple, and could be very powerful.

As a simple example, I want to set the APPLICATION_ENV variable to production if the website is http://www.example.com, and development if the site is beta.example.com. This worked:

SetEnvIf Host "www.example.com" APPLICATION_ENV=production
SetEnvIf Host "beta.example.com" APPLICATION_ENV=development

That was the initial code. Of course, after reading through the manual, I read about SetEnvIfNoCase, which is the same as SetEnvIf, except the “matching is performed in a case-insensitive manner.”

SetEnvIfNoCase Host "www.example.com" APPLICATION_ENV=production
SetEnvIfNoCase Host "beta.example.com" APPLICATION_ENV=development

Pretty simple.

TDD: Test Driven Development

One problem I have with the two big TDD sets out there for PHP (SimpleTest and PHPUnit) was the incompatibility of working in the setup I am working in. SimpleTest apparently wanted to take over error control, something my environment was already handling, and PHPUnit didn’t have a web interface by default. Finally, both wanted to do things their way. None of this is bad, but working in a shop were Unit Testing isn’t the norm at the moment (though momentum exists for the change to take place), I didn’t have time to play around with getting them setup properly. But I wanted to test.

So I did what any programmer would do in my place: I started building my own simple testing sweet. Testing doesn’t have to be complicated. It doesn’t have to involved massive amounts of setup and tear down. In reality, at the very heart of it, just getting some form of tests started is part of the path toward redemption.

My current testing platform is very, very simple. It consists of a file that displays all the tests available to run in a directory (or packages of tests in sub-directories of the main test folder). You click a link and it runs the appropriate test. It then prints out a simple page that shows the number of successful tests.

Basic Testing Screen — The basic testing screen gives me immediate, important feedback: Did the tests succeed? Did the tests fail?

Here is a completed testing screen. As we can see, it ran the test, and seven tests failed, and four passed fine. We can review the test below inside the testing screen, saving us even more time. But all this is fairly useless beyond that. We know quickly that the test failed. Now we have to fix those tests. This gives us a list of things we have to fix, a ‘todo’ list of things that need to be addressed. But, what exactly do we need to fix?

We can click on the text right above the test results and it will give us this information.

Expanding testing information — Clicking the text right above the testing results expands the result view to show all the tests run, and their results. Errors first, as they are the most important.

Now you can see where the fun comes in. Clicking the text expands the details (using jQuery), and now we can see all tests that failed and passed, where they are by line number, and what they received in testing, and what they expected, as well as why the test failed. We can now trace the errors to each line of code, so we know exactly what code caused this to fail, or more precisely, what test failed. The same works for the tests that passed. Of course, even this isn’t as efficient as it could be. Granted, this provides us with enough information to work with, and in some cases, it’s all the information you need. Information overload is something I wanted to avoid. I don’t need to see more than this, except sometimes I do.

Test Details — This is where we start to really dig deep. We can now view each test, where it ran in the testing script, what it expected, what it got, and it even shows the code used to perform the test so their is no confusion.

Clicking on the top Failed or Passed boxes will expand all the associated tests to further details (again, using jQuery). We can also click on tests to open them up one by one, allowing us to view only what we want. This lets us see what the offending code was that caused the failure without having to go and look for it. This is most useful when we have an unexpected error.

Getting to this point is quick and easy. Drilling down doesn’t require any real effort, and we review things as we go along. We see the failures, we open them, and we allow ourselves the opportunity to review all the errors without forcing ourselves to become overcome with too much information. We can focus on what we need to work on at the moment.

Finally, at the top of the page, the name of the test is also set to rerun the test. This is done on purpose because this testing page sits inside a frame. I use the frame as a type of bookmark for in-house development tools and sites, frequently used links that I don’t want to put in any one browser. After all, I’m generally working inside Firefox, IE, Chrome, and Safari, usually at least two of the four.

There are some problems with my setup. The packaging of tests is really dirty at the moment. Every tests needs to exist in a certain directory. Each tests also needs to start with ‘test_’, and a name like ‘test_AlwaysFail.php’ turns into ‘AlwaysFail.’ ‘test_Always_fail.php’ would be run as the test ‘Always fail.’ But this also means each test file is self-contained, and considered on test. I’ve setup a way to run all the tests at once, but it’s cumbersome, and doesn’t work like it should: quickly, easily, and efficiently.

I also need a way for tests to better document themselves, and a way to automate this feature.

Tests also run when you click on the initial testing link. While this makes testing easy, testing isn’t always about just running the test. There should be someway for me to allow for a launcher page, a way to go to the test page and let me do something if I want, even if it’s as simple as reviewing the tests that will run.

I should be able to run multiple test pages together in a certain order. Setting up a test is important, but I want to test that setup, as usually it’s using the tools I want to test in the first place to do the setup. At the same time, I want setting up test requirements to be easy. This is where the above idea of having a launcher page might be best. Allow me to go through a series of tests step by step, or all at once.

The general theme here is focusing on using tests as development tools, not just as error checking devices. Of course, being able to run all the tests and get an easy to use report is critical.

I don’t imagine for a second my testing platform is as mature as any of the other ones out there now. However, I didn’t start out with the intent of building one. I just needed a simple way to run tests. Then I needed a way to report tests. As time dragged on, I would add one feature, and then another, and keep adding as I needed them. I didn’t spend time developing this, it just evolved.

This all isn’t to suggest that SimpleTest or PHPUnit are bad. I’m using them as a reference for some of the ideas I’m having. But I always focus on how to take what they do, and make it fit with what I want.

Hello world!

I’ve tried multiple times to restart blogging. I’ve blogged before. The site was newbienetwork.net, and then became phpcomplete.com. Both were fun, new, exciting, and interesting. I was learning to program, learning PHP, and teaching others along the way.

Of course now I’m old and jaded. I’ve been programming for 10 years now, and I’ve been focused on credit card processing for the past 8 years. Specifically, I’ve been focused on credit card processing for the adult industry. 8 years of doing that, in an industry that makes it a challenge as well as interesting. Don’t get me wrong. I love what I do. I find everything I’m involved with to be a challenge. There is a lot more that goes into it then people think. However, I also want to break free.

At least on a personal programming level. PHP programming for so long means I know what I’m doing. I have an easy grasp of PHP. I understand how it works, I understand web development as a whole. I know it well enough that I feel comfortable with it. The problem is, I need to branch out.

Of course, the question is, what do I branch out into? I’ve dabbled with game programming using C# and XNA. This has been a recent bit of fun. I’ve wanted to try Java, but frankly, Java is filled with so many options its rather daunting. Where do I start? Maybe the same place I started with C#? A book! But then why not get back into C++. I’ve done C++ early on, but I stopped when PHP became my focus. I could get back into it, but all this is beside the point.

What would I create? More importantly, why build it in any of these languages? So much is web-focused these days that in many ways, it’s worthwhile to learn the new things coming out for the web. Become more fluent with JavaScript, CSS3, and HTML5. Canvas looks amazing. There is so much room for growth. Seeing what people are creating online makes me wonder why I should worry so much about programming offline.

Consider that I am busy learning Zend and Doctrine. Now, I know them well enough I can work with them, but frankly, I don’t consider myself as knowing something until I can avoid using the documentation and I just hammer out code. Both Zend and Doctrine are big, monstrous pieces of code and each have lots of options, do lots of things. Granted, I don’t think I’ll ever really learn every aspect of Zend. Lots of packages, lots of tools I don’t need every day. But there are also a large number of things Zend does that I should learn.

Of course, after I think about all that, I think about what else I am learning. I’ve been pushing myself to use TDD every day, in everything I program. Constant Integration, Agile development, documentation, version control. So much going on every day, so many new things happening.

In the old days, you got a website, you put up a simple page with SSI header and footer, and you were happy. You copied a Perl script, dumped it into cgi-bin, hoped it worked and didn’t throw up a 500 error, and that was your web page.

Oh the old days. I miss, but frankly, these days are a lot more fun.