1. Prevent, Don’t Scold
2. Give Immediate Feedback
3. Let the User Work
4. Innocent Until Proven Guilty

The first rule ties in nicely to a post I just wrote on putting the user in a place where they can succeed. I don’t want to waste time here re-iterating what’s said there, but give it a read—at least that part about best practices—and keep that perspective in mind the next time you go to design a user interface.

The first key number is that if the book lists for $30 (all numbers are in US dollars), then the publisher probably gets around $15. This is why Amazon and bookstores can mark the price down 20 or 40% and still make money on the sale.

Now the Times article suggests that the writer gets a 15% royalty on the $30. That may be the case for some, but, in working with two publishers (and having preliminary contract negotiations with another), a 14% royalty rate is the best I’ve personally seen. For many books the rate is actually 10 or 12%, and one contract I had started with royalties in the single digits, possibly escalating up to 10% or so as sales increased. As far as I can tell, the royalty rate a writer gets is based upon the expected and actual sales of the book and what the publisher thinks they can get you to agree to.

But, most importantly, the royalties are calculated on the price the publisher gets, not the list price (in my experience; I don’t want to question the accuracy of the Times article, but it’d really surprise me if any writer is getting paid royalties on the list price). So, if you do the math, a fortunate computer book writer can hope to get maybe $2.10 for each book sold (14% of $15). As for myself, I need to take out payroll taxes and cover business expenses, so at the end of the day, for each book sold, I’ll probably have $1 or thereabouts in my bank account that can be used to pay the mortgage and buy groceries. Yes, one dollar. (Not to belabor the point, but you may want to ponder that $1 the next time you go making demands of a writer or think they’re just doing X, Y, or Z to make money.) If I sell a copy of an eBook or a translation, I’ll get half that. This means that when a reader in India insisted that I put PHP, Apache, and MySQL on a CD, along with whatever other materials I may have (and I don’t have any that I’m keeping to myself, really), and ship that out to him in India, at my expense, that was after he had given me about 50 cents (or four-bits if you’re old-school). Kind of crazy, eh? Of course, I’m not trying to disparage readers, and people in all situations make unreasonable requests, I’m just saying that this is my experience as a computer book writer—but I’m a fairly successful writer—and this is pretty eye-opening for most readers.

Looking at the publisher again, the Times article puts their net, after the writer’s royalties, printing and shipping the book, marketing, and other book-specific expenses, at about $4 ($4.50-$5.50 for eBooks). And from that four to five dollars, the publisher has to pay employees, provide health care, have physical offices, etc., etc. So there’s not a ton of money being made by the publishers either, and that’s when a book sells. When a book doesn’t sell, it’s just a loss of money, because the publisher still paid the printing and shipping costs, plus they gave the writer an advance. My understanding is that about the top 20% of bestselling books helps cover the losses associated with the other 80% (and that most of these numbers are also appropriate to the music industry).

So there’s a little insight into the publishing business, from a money perspective (again, read the whole NY Times article if you want more and better details). As always, thanks for reading what I have to say!

I fill out the form properly, I thought, then click submit. At that point I see a message about my chosen password being invalid because it didn’t contain both upper- and lowercase letters, plus at least one number. That’s a fine requirement, of course, but why didn’t the registration form indicate those requirements? It’s obvious that an email field needs a valid email address, but if you’re developing a site and you know that you’re going to validate a field to confirm that it includes both upper- and lowercase letters, plus at least one number, how about telling the end user that, too? So here’s the first, most important rule of a good user interface:

A proper user-interface sets the user up to succeed.

Whether you’re designing a Web site, managing a group of people, or being a parent, you have to put your users, employees, and children in a place where they can do things well. And by “well”, I mean: they can do things they way you think they should!

Conversely, I just finished doing my United States taxes, which I always do online using TurboTax. I use TurboTax primarily because the user interface is extraordinarily well done. For example, it’ll ask you a seemingly random, strange question, like “Did you roll over the proceeds from a farming operation into a non-work-related 403b?” I might look at that and go “huh?” but one great thing TurboTax does is add parenthetical notes like “This is not common.” Simple and brilliant. And TurboTax has other nice features, like indicating where you are in the process, reviewing the data you’ve entered, and so forth, but the clear messages—right where I’m focusing at that moment—make it easy for me to use the system properly.

It can be tricky for developers, who are theoretically quite knowledgeable about computers, to put themselves in the mindset of an end user, but there here is one simple way to create a successful user-interface: look at what you’re doing on the server side of things. If you’re going to check a password field for a number, put a message on the form saying a number is required. The same goes for a length requirement. If a date will be validated against a given format (like four digits for the year), have the form indicate the proper format, too. The same goes for phone numbers. If a username can’t contain a space, say as much. Set the user up to succeed instead of making them feel stupid for not doing something they weren’t told to do in the first place!

One significant change, which I’ll have to address in a separate post, is support for unit-based testing. The concept of unit testing has become more and more popular over the past few years, and has slowly been making its way into PHP development. The premise is simple: as you develop an application, you write a series of tests that evaluate bits of code. With unit testing, you really want to test isolated, atomic parts of an application. One of the many benefits of unit testing is that as your application grows and becomes more complicated, you can quickly apply the established unit tests to insure that the core components are still working as they should. Yii now auto-generates some testing code for you. Again, I’ll try to write up how you’d use unit testing at a later point.

A second change, that’s perhaps more evident, is the creation of an official library of Yii extensions. These are all filed under the Zii heading (i.e., in the framework/zii directory). To start, there’s a group of jQuery User Interface (jui) extensions, plus several for creating data grids and lists. A couple of standard Yii components, like Menu and Portlet, have been moved to Zii, and I like having the breadcrumbs extension in there. I’ll try to write about that separately as well.

Third, Yii now has a form builder. Much like PEAR’s HTML_QuickForm2, Yii’s form builder makes it easier to create and validate forms without lots of redundant code. I think the Yii manual has a fairly good explanation of this, but I’ll write it up separately if people feel there’s the need.

There are also a number of behind-the-scenes changes, especially as to how related Models are fetched using the Active Record Model. In terms of existing code, Yii 1.1 dropped the safeAttributes() method from Models. This is smart, because I for one never fully understood when something should or should not be marked as a safe attribute. Now safe attributes are those that are validated by other Model rules.

Finally, if you’re already using Yii for some projects, here’s what the Yii managers say about using Yii 1.1: If you are already using Yii 1.0 to develop your project which is about half-way done, we suggest you do not upgrade to 1.1 because there are quite some changes that break backward compatibility. If you just started a new project, we recommend you upgrade to 1.1 because it will receive most of our maintenance effort from now on. While we will continue to maintain 1.0, we expect it will only receive bug fixes in future. If you are new to Yii, you should start with 1.1.

From my post on Models…

The only difference I found is that Yii did a better job of recognizing the relationships between the Department and Employee Models. Specifically, it picked up both relationships: that multiple employees are in a single department and that one employee is the department head. Here’s the relations() method from the Department Model:

public function relations()
{
    return array(
    'deptHead' => array(self::BELONGS_TO, 'Employee', 'deptHeadId'),
    'employees' => array(self::HAS_MANY, 'Employee', 'departmentId'),
    );
}

The Employee Model’s relations() method also reflects both relationships.

From my post on Views…

Yii 1.1 has taken a bunch of the best extensions and placed them in their own namespace, zii. A lot of functionality is now added to sites by using widgets from within the zii library. Whereas earlier versions of Yii created a MainMenu component, Yii 1.1 uses the CMenu widget. The default layout also makes use of the CBreadcrumbs widget, include in the zii extensions.

There are a number of View file changes, although none that are dramatic: What was previously the list (list.php) View file is now index (index.php). The index page makes use of a CListView widget to list the records. The admin page makes use of a CGridView widget to display all the records. The show file (show.php) is now called view (view.php). It makes use of the CDetailView widget to show the information for a specific record. Multiple View files can make use of the _view.php script, which is a template for showing an individual record. Every view file identifies breadcrumb information at the top, which will tie into the CBreadcrumbs widget referenced in the main layout file. I’ll try to write up using the breadcrumbs widget at a later time.

From my post on Controllers…

No major changes here. The $defaultAction line is no longer present. Also, the names of some of two of the action methods have changed to match the new names of the corresponding View files: actionView() and actionIndex().

So, with that in mind, here’s what I’m working with for starters. It’ll undoubtedly change and there are a few things I want to fit in somewhere, like accessibility. As always, any thoughts, questions, and suggestions are most welcome!

Introduction
--------------
Part 1: The Fundamentals

Chapter 1: Building Flex Applications
 A Survey of the Parts
 Using Flash Builder
 A Cheaper, Slower Alternative
 Deploying Applications
 Getting Help

Chapter 2: Basic User Interface Elements
 Application Layouts
 Simple Controls
 Creating Forms

Chapter 3: The ActionScript You Need to Know
 Data Binding
 Syntax
 Comments
 Simple Data Types
 Control Structures
 Arrays
 Creating Functions
 Best practices

Chapter 4: Event Management
 The Event Phases
 User Events
 Application Events
 Handling Events with ActionScript
 Preventing Events

--------------

Part 2: Data and Communications

Chapter 5: Common Data Formats
 XML
 JSON
 AMF

Chapter 6: Simple Local Data Interactions
 Displaying Data
 Formatting Data
 Validating Data
 Using Local Data Files

Chapter 7: Simple Remote Data Interactions
 Sending and Retrieving Text (HTTPService)
 Sending and Retrieving XML (HTTPService)
 Sending and Retrieving JSON (HTTPService)

Chapter 8: Smarter Remote Data Interactions
 WebServices/SOAP/WSDL
 RemoteObjects/AMF

--------------

Part 3: Application Development

Chapter 9: Modularization
 Creating Custom Components
 Using Modules
 Using Runtime Shared Libraries

Chapter 10: Creating a Fuller Experience
 Menus
 Navigation
 View States
 Creating Histories
 Deep Linking
 Accessibility

Chapter 11: Windows and Popups
 Alerts
 Popups
 ToolTips
 Changing Window Behavior

Chapter 12: Improving the Appearance
 Multimedia
 Style Sheets
 Skins

Chapter 13: Effects and More Events
 Effects
 Drag and Drop
 Custom Events

Chapter 14: Testing and Deploying
 Testing Techniques
 Profiling an Application
 Improving Performance
 Network Monitoring
 Customizing the Deployment

Yii now creates two bootstrap files in the Web root directory: index.php and index-test.php. They are exactly the same except that index-test.php includes a different configuration file: /protected/config/test.php instead of /protected/config/main.php. However, the test configuration file just includes the main configuration file, then also enables the CDbFixtureManager component. This component is used to perform unit testing, a new addition in Yii 1.1.

Unit testing is all the rage in programming the past few years and it goes like this: you define very specific tests for different aspects of an application, then you run the application against those tests to confirm that things work as they should. As you build up and even refactor your code, you can continue to run those same tests to confirm that you haven’t broken some functionality in the process of adding new.

Anyway, Yii is suggesting now that you run your site through index-test.php to use unit testing during development stage, then switch to index.php for the live stage. Even if you don’t use unit testing, this is a nice model for having two configuration files: one for development and testing and one for live settings.

From my Creating Models, Views, and Controllers in Yii post…

The files generated by the CRUD commend have changed. You still get the controller and all of the View files, but the show.php file is now called view.php and the list.php file is now index.php. Both are still used to show the specifics of an individual record and list them all, respectively. There’s also a new View file called _view.php. This is a little template to display the information for a specific record. It’ll be used by view.php. Also three files for unit testing purposes are generated and stored in three subdirectories of protected/tests.

It looks like supporting unit testing is the main change thus far (for what you’ll see as you just get started). I’ve gone through five of the eight posts in the series and everything still works, you just get more stuff now. I’ll try to write up a post on unit testing separately and in a couple of days I’ll go through the separate Models, Controllers, and Views posts to check them for changes (at the very least, we know that some of the View files have changed names).

Personally, I use a text editor for my PHP development (TextMate for Mac OS X). But I have used Eclipse quite a bit, just not for PHP. Eclipse is a standard foundation for lots of IDEs, like Flex Builder/Flash Builder and Aptana Studio. I’ve used Netbeans for Ruby development. Both Netbeans and Eclipse are quite good and extremely extendable, but not as user-friendly as some commercial products, in my opinion. I never really took to Zend Studio, for no particular reason. Maybe the price! I did use NuSphere PhpEd for a while (I did some consulting work for that company) and it seemed to be a very likable solution, but it only runs on Windows, which rules it out for me.