Professional PHP5 (Programmer to Programmer Series)
ISBN: N/A
EAN: N/A
EAN: N/A
Year: 2003
Pages: 182
Pages: 182
In the early days of the Web, long before PHP came onto the horizon, the user experience that is, the impact on the user of using your Web site was largely unimportant. Content was key. In fact, content was all there was. The Web was little more than a magazine with convenient tabs for ease of turning the pages.
No more. The Web is more and more accepted as a superb mechanism for implementing thin client applications, from the simple Webmail facilities of an entertainment portal to the sophisticated multiuser inventory control network of a big corporation. This capacity is, after all, why you learned PHP in the first place.
Unfortunately, the adoption of the Web as a means for implementing thin client solutions has been less than plain sailing. Many authors have omitted (perhaps with the best of intentions) providing modern-day equivalents of the key features that made thin client architectures of yesteryear usable.
One of the biggest of these is the capacity for communicating with users outside the context of the immediate user interface. Consider an abstract example. The immediate user interface of a telephone consists of the mouthpiece and earpiece. Yet, all telephones include ringers so that you know when a call is incoming. This is an example of notifying the user of an event.
A second example is the fax machine. Many fax machines print a delivery report when a fax has been sent successfully. This report is auxiliary to the keypad and LCD display, which constitute the immediate user interface, and is an example of keeping the user informed.
One final example. If you have ever applied for a bank loan over the phone, you have doubtless found acquiring debt in a matter of minutes remarkably easy. Still, the bank sends papers for you to sign to your registered home address. Even if you are approved in principle over the phone, the money doesn't go anywhere near your checking account until you sign and return the papers they sent you. This is an example of using communication with the user as a form of security, a form of validation.
There are other examples. But this chapter examines how those mentioned here have an impact on the real world and how you act on them through OOP mechanisms.
Take these three examples and try applying them to the Web. Examine why you might want your application to notify, inform, or validate your users.
A number of scenarios can arise in which you may want to notify your users of something through a means other than a Web browser.
This issue is particularly relevant if you remember that HTTP is what is known as a stateless protocol. It is not particularly easy to get the Web browser to sit there and wait for something to happen before informing the user. You can do it in various ways, but none is particularly pretty.
Imagine that your application has a sophisticated reporting system that allows users to request reports on all manner of business details. Particularly if those reports are extremely SQL intensive, a strong argument can be made for generating those reports offline that is, independently of any Web browser usage. That way, the user is not presented with any excessively long request in order to view the report. It is simply not realistic to guarantee the user will not give up and click Stop halfway through a two-minute wait for a page to be generated. In a real-world-scenario, the user would use the Web browser to order the report, doing so in the understanding that the system would notify him or her when the report is ready.
In another example, imagine that a subscription Web site is set up to bill the user's credit card automatically every month on the first of the month. It wouldn't be terribly good customer service if, because the user's credit card had been declined during that month's billing process, the user were simply unable to log into the Web site. Instead, you would issue what is sometimes known as an exceptional notification a notification that occurs as a result of something out of the ordinary (typically, bad) happening in the form of an e-mail inviting the user to log on and give details of one of his or her many other valid credit cards.
Notification is not restricted to e-mail, of course. Operators of data centers all over the world have fallen in love with SMS (Short Message Service) notifications to their cellular phones to advise them when vital servers or processes have fallen over, regardless of where they are at the time.
Communicating information to users differs slightly from notification in that it is not necessarily event driven. Instead, it is a fully expected communication issued with the intent of updating the user as to the status of something. Compare the arrival of the morning newspaper on your front porch with a sudden notice from the Emergency Broadcast System during a television show. You expect the newspaper's arrival, but the notice of impending blizzards in Tampa Bay come as a bit of a surprise.
A good example of keeping users informed is that of a weekly newsletter from a subscriber Web site. This could be something automatically generated by tabulating an extract of that week's news stories, or it could be something put together by an editorial team. Either way, you're keeping your users up-to-date.
Another good example is an order update from an online e-tailer. If seven days have expired without the arrival of the books you ordered, you might be getting worried, and you would undoubtedly be reassured by an e-mail explaining that the books are still on order. Again, this is not a notification. Nothing's changed. Nothing's new. It's just a quick update.
This means of communication is perfectly adaptable to other information methods fax, text message, snail mail you name it. You'll learn shortly that the various communications media you may previously have thought to be completely different are in fact virtually identical (at least from a software architecture perspective).
Validation is often a means of communicating once for the purpose of communicating again. You validate a destination address of some description so that you may reassure yourself of its accuracy should you need to use it again. Alternatively, you may have some piece of information your user wants, but to be doubly sure of the requesting user's identity, you will send that information only to the user's registered address.
The bank loan example on the previous page represents the more serious side of things. After all, the bank wants to verify your correct address so that it can send the repo men in if your repayments are tardy. Numerous Web sites, however, validate e-mail addresses in this way for later direct marketing usage. The simple way to do this is to send out an activation link (usually presenting some kind of unique key stored against the user's record in the database) to the e-mail address offered by the user. The user must click the link to activate his or her membership.
Similar methods can be used to throw a rope to users who've forgotten their password, although it isn't usually either a good or feasible idea to tell reveal their password via email. You shouldn't be storing their password unencrypted or in any reversible form, or transmitting it in plain text over e-mail. You can certainly provide them with a link (generally of limited-time validity) for the purposes of gaining temporary access to your site so that they may set a new password.
In Europe, where it is increasingly common to communicate with web site visitors via their cell phones as well as via e-mail, some sites send an activation code as a short text message to the cell phone number the user offered at registration. The user must then enter that activation code on the site to prove the validity of the number he or she provided.
As an aside, this SMS code-sending technique can actually be used as a poor man's form of second-layer authentication. Authentication on systems is generally provided by one or more of three keys. These are something you are (a fingerprint, iris scan, or even originating IP address), something you know (a password), and something you have (a key or fob). The accepted wisdom is for any system guarding data of any kind of sensitivity to implement more than one of these mechanisms. By sending a unique code to a registered mobile phone upon entry of a username and password, that extra layer of protection is provided.
By realizing the potential of alternative communication mechanisms (particularly e-mail), you offer users a far more enhanced user experience on your site. Take a look at how you can implement this in PHP (beyond the mail() function, of course).
| Important | It's probably worth stressing that the mail() function in PHP is to sending e-mail from your code what a ten-year-old's treehouse phone is to digital telephony. It should never appear in serious production sites. |