Feel free to try it out, and let me know what you think!

I have seen this many times, and often it is even further shadowed by the fact that the product or site is popular with its customers, or that people have used it for a long time, so it must be fine, right? Wrong. Just because people are buying or using your product doesn’t mean there aren’t problems with it, or that it doesn’t need improvement. And you can’t always rely on the customer to tell you what they want to see in terms of UI, because they often don’t know — they just want it to work with the least amount of effort necessary.

This is the concept that is important to keep in mind when developing the application as well, as many complex applications have complex UIs that are completely necessary. It is often assumed that flexibility requires complexity, but there are many good examples that this is not the case. A good working example would be the file search feature in Apple’s Mac OS X Finder.

Search Options in Mac OS X Finder

Rather than bombarding the user with every possible option, they are initially presented with a simple search field, present at the corner of every file window. Typing in that field will initiate a quick search for files that match the entered text, and the toolbar shows just a couple of options, allowing the user to specify if they want to search the entire computer or just their folder, and if they want to show all files that contain the text, or just ones whose names match. Clicking the plus sign to the right offers an additional row, allowing the user to further refine the search by selecting a property and a condition (i.e. “Kind” is “PDF” or “Name” “begins with” “Agreement”). The user can then continue adding these filters to obtain as much detail as they need. While the display can become cluttered with several of these filter bars, it is not as confusing or overwhelming as the countless and little used search boxes may be on some “advanced” searching interfaces, where the user must look through a wide array of fields to determine which fields require input to filter results.

It is this mindset of keeping UI elements simple and relevant to the user that is necessary for sites and applications to thrive. If your interface is clean, simple and functional, not only will users buy your product or service and continue to use it, but they will actually enjoy using it and be more likely to offer positive recommendations to others because they enjoy it.

So to execute a service on another machine, the front-end server would have an object definition, which would both provide a defined structure for the object (such as a payment), as well as offering some common methods to perform a remote request to the backend server to actually do some work. When the object was ready to do something, it would call its own request method, passing in a URL to an interface page, and the request method would handle building an XML request based on the properties of the object, posting the XML to the page that was passed in, and then returning the XML response when all was done. On the other side of the picture, the page that is handling the request would in turn initialize a similarly structured object, which was defined with the necessary methods to perform the work requested (such as processing a payment). For example, in order to call the MakePayment method on the payment object, the frontend would need a MakePayment method, which sets up the payment details and initiates the XML request, and then the XML interface would need a handler created to set up the payment and handle calling the MakePayment method on the actual object on the backend server.

Definitely not the most elegant solution, but it made the most sense when we originally encountered the need to pass requests between servers, particularly due to the language differences I mentioned earlier.

Some of the best and craziest ideas happen by chance, and that’s exactly how I stumbled upon this idea. A coworker was having some difficulty with one of the services, and was slightly confused by which code was causing the problem, as there were effectively four components in the mix — the display page on the frontend, the service’s object definition, the XML interface on the backend server, and the “real” object definition there. After seeing the error he was getting and having a look at the code, I determined the problem was that he was just missing a method definition on the frontend, and would need to create one. When I explained this, however, he responded with a simple question: “Why can’t I just call this method directly?” My initial response, of course, was to say “because it’s on another server” and that you can’t simply make calls across systems like that, but then I started wondering exactly the same thing — why not?

I knew that you could transfer information across systems easily by storing session data in a shared database, and I started to wonder why a similar principle wouldn’t work for directly calling methods. So the solution I came up with is actually relatively simple: serialize the request object and send the entire object over the POST to the other server. The handler on that server just needs to unserialize it there, and call the requested method, and then serialize and return the response. I further simplified this by defining a __call “magic method” on the template object that automatically facilitates the request, allowing you to call any method that is defined on the backend server’s object in the code on the frontend without having to define the methods on both servers.

There are, of course, some gotchas to watch out for (some objects can’t be easily serialized, such as SimpleXMLElements), but for the most part this works pretty well and requires very little code to function on the frontend server.

To accomplish these tasks, I have written a couple of classes that are intended to simplify things. Rather than completely reinventing the wheel, I started with the excellent open source SubnetCalc project by Ramond Ferguson. I adapted the existing code into an object-oriented class structure, and updated the regular expression handling to use the superior preg_* functions to improve speed and future compatibility, as ereg has been deprecated. In addition to the detailed subnet calculation functions already offered by the project, I have added a few new features:

• Test if a given IP is a valid address
• Determine IP type (node, network, or broadcast) based on the associated subnet schema
• Test whether an IP is within in the subnet’s address range
• Dynamically alter the subnet schema — calculations are automatically updated to the new values

They always say the proof is in the pudding, so here are a couple of usage examples. First, let’s create an IP object. The class will automatically test to see that the IP is valid, and throw an exception if it’s not:

try {
	$ip = new IPAddress('192.168.1.12');
} catch( Exception $e ) {
	print $e;
}

To assign a subnet mask, you can call the SetCIDR method:

$ip->Subnet->SetCIDR(24);

And now your object is populated with a handful of useful calculations:

IPAddress Object
(
    [Address] => 192.168.1.12
    [Subnet] => Subnet Object
        (
            [Class] => C
            [Netmask] => 255.255.255.0
            [CIDR] => 24
            [Wildcard] => 0.0.0.255
            [Network] => 192.168.1.0
            [Broadcast] => 192.168.1.255
            [FirstHost] => 192.168.1.1
            [LastHost] => 192.168.1.254
            [Hosts] => 254
            [Private] => 1
        )

)

You can also use the Subnet object by itself to perform simple calculations without a specific IP address, and you can call the IsValidHost() method to test an IP address to see if it fits in the subnet. An example of how this might look:

try {
	$subnet = new Subnet("192.168.1.0/27");
        print $subnet->IsValidHost("192.168.1.21") ? "YES" : "NO";
        print $subnet->IsValidHost("192.168.1.64") ? "YES" : "NO";
} catch( Exception $e ) {
	print $e;
}

In this example, a subnet is created, with possible hosts from 192.168.1.1 to 192.168.1.30. So the first print statement would display “YES”, since node 21 falls within the subnet, and the second statement would display “NO”, as node 64 is not part of the subnet.

If you would like to try these out for yourself, you can download the classes here. Thus far, the class seems to work well for my purposes, but as this is based on some unfamiliar code from another project, I could have easily missed something. I will continue to fine tune the code, and will be doing some minor cleanup on the imported functions as time permits, so be sure to check back periodically for any updates.

The way refunds are handled is explained (very clearly) in the developer agreement, and each developer signs and agrees to that agreement. What you don’t do is, knowingly sign a contract and then complain about the terms. What you DO do is, don’t sign the contract at all if you don’t like it.

Every developer knew – before they signed – that the refund process meant they could be refunding more than 100% of their revenue. Their only two options – complain and don’t sign, or sign and don’t complain. Those who sign and complain have only themselves to blame, they KNOWINGLY signed up to this deal!

Actually, if I remember correctly, for many developers the refund option didn’t even exist initially, and many developers were upset when it appeared in a later update to the agreement.

Either way, it’s a good point, since developers pretty much do agree to those terms just like many consumers agree to ridiculous terms on credit cards, and then complain when they are hit with huge fees because they didn’t actually read what they were agreeing to. And in this case, it’s no fault of Apple’s if the dev didn’t read their agreement. Luckily, in most cases, it doesn’t appear that Apple enforces it anyways.

I do believe, personally, that users should only ever get from the developers the amount the devs have actually been paid, and no more, but then, I didn’t sign the agreement, hey.

“And yes, there are over 10,000 developers, 65,000 apps, 40 million devices, and 1 billion downloads from the App Store. But none of that matters unless you realize that the developers themselves are directly responsible for much of the iPhone’s success. By alienating those developers through inconsistent policy handling and refusal to communicate one-on-one with them to resolve problems, Apple is setting itself up for failure.”

I disagree with this. I think it *does* matter that 10,000 devs have made 65,000 apps without much hassle, and yet the number of rejections and complaints is … what? A dozen? A few dozen?

Okay, I could have used better wording instead of saying “It doesn’t matter,” but I think you underestimate the number of rejections and complaints that actually happen. Yes, when compared to the total number of 65,000 apps, even saying as many as maybe (just throwing a number out there) 5,000 of those apps were rejected seems insignificant.

But looking at it from a different angle, we here at TUAW get a good number of e-mails regarding apps that were rejected or complaints about the approval process on a DAILY basis. Yeah, some are repeats and some days are more than others, but still, there is a much larger volume of rejections and complaints than what actually gets covered in the media.

I think it is very important for you to put things in context, otherwise you are misrepresenting the true situation – you’ve basically made it sound, from the article, that all developers have a problem with Apple, when in fact, we’ve only heard that a dozen or so do (out of 10,000 – that is a very small percentage!)

Agreed. But what I believe the real problem is doesn’t lie in the number of developers affected, as much as in the significance of the problems those developers have faced.

If it were just a handful of devs getting apps rejected for blatantly violating terms of the SDK, I don’t think there’d really be much to complain about, and we wouldn’t be having this discussion. But what’s happening is individual developers hit snags with Apple, where they follow all of the rules but, for one reason or another, Apple removes/rejects their app or some other problem arises that makes everyone stop and wonder what is going on.

And it is here that Apple stumbles, because they don’t deal with the problem in an efficient manner, they usually either give vague, inconsistent responses to the developer, or they choose not to communicate at all. Then the developer gets upset, the media gets involved and it becomes a big PR nightmare, and only then does Apple (sometimes) step in and make an attempt to remedy the situation. But by that time, the damage is already done.

I also disagree with the overall tone of the article which suggests that Apple benefits from developers while developers do not benefit from Apple at all.

That’s not the tone I intended, so I apologize if that’s what you’re getting from it. The intention was to express and convey the frustration with Apple’s decision to pull the GV apps, and claim that they were “duplicating functionality” rather than being open and honest with developers about the true reasons for their removal and offering methods of recourse; their lack of communication to the parties involved when they encountered the problem; and the effects of penalizing the developers with refunds for a decision that really was not the developer’s fault.

No developer designed, created and marketed the iPhone and App Store. That was Apple. But developers have been able to use this new market to make money – we know that some devs have profited (and profited well) from the App Store. So I think it is abundantly clear that devs have benefited from Apple as well as the reverse.

Completely agree.

Lastly, I don’t agree that Apple is setting themselves up for failure – I remember similar comments about Nintendo abandoning the polygon count race, and we know how that turned out.

Sometimes, decisions that look wrong on first glance, turn out to be right. This has been true of Apple in the past. It was wrong for Apple to launch a smartphone without copy-and-paste, without multitasking, without a replaceable battery, wasn’t it? More like 40 million points of right. Apple correctly identified what people wanted and needed, while most everyone else fell over themselves declaring that Apple had set themselves up for failure.

This can be interpreted very differently, depending on how you define failure. Do I think that the App Store will collapse, killing the viability of the iPhone platform and destroy the future of Apple? Definitely not. But I think that it is reasonable to believe the App Store (and by effect, Apple) could ultimately be less successful as a result of these problems. Sure, they might have achieved their goal to create a viable platform that allows developers to easily create apps and users to easily find those apps, but the attitude they choose to use when interacting with developers and dealing with problems harbors more dissent and unwelcome feelings among the community, which has proven to be detrimental to many platforms over the years.

I think you are discounting how much the iPhone’s and iPod Touch’s stability and friendliness comes from Apple’s “crazy” rules and the heavy-handed imposition of them, and I think you are blatantly assuming that Apple has had no reason to ever pull and reject apps. Apple might not be saying, but that does not mean that they don’t have a reason and that it isn’t a good one.

Valid points, though I don’t assume that Apple has had no reason to pull or reject apps. My contention lies in the fact that they hide their reasons behind vague and inconsistent policies. If you’re going to reject application X for having a particular feature, then you need to reject applications Y and Z if they have the exact same feature. To me, it’s fine if they have to pull an app from the store, but they need to take the developer of the app aside, and explain to them exactly why it is being pulled, and what options of recourse they might have to prevent it (if the pulling is due to a specific element of the application).

I mean, seriously, the developer is already under an NDA, so just remind them that under the terms of that NDA, they cannot disclose the reason the app was pulled to the public, and take them to court if they leak the details. And, if for some reason Apple simply *can’t* disclose to the developer their reasoning, don’t hide behind a vague claim that is obviously untrue, but instead tell the developer outright that they are unable to disclose the details, and then offer an olive branch to them by suggesting some form of recourse or compensation or *something* for the trouble.

But yeah, I agree that they might have reasons that they are not willing to discuss. And if they are going somewhere with those reasons, that’s fine. But they still need to keep an open line of communication to the developers. Even if that just means someone calling them up or sending a personal e-mail an saying something like this:

“Look, I’m really sorry, but we have to pull your app from the store. You didn’t do anything wrong, but we have to remove it for technical reasons. I’m afraid I can’t go into details at this time, but we will do our best to let you know if and when it can be resubmitted. I realize that you have put a lot of time and effort into this application, and due to the circumstances, we are willing to offer you ________________. In exchange, we ask you to keep the terms of this arrangement confidential, please inform users that the application had to be removed due to technical difficulties. In the event that refunds are requested, we will work with you on those cases.”

To me, a simple conversation like that would go A LONG WAY to keeping good spirits about the situation. Yes, it would still be a bit frustrating, but at least you’d have the feeling that *someone* at Apple actually cared, which unfortunately, doesn’t seem to be the case with many of these stories.

Ok, I’m done now.

$Report = new Report( "My Report" );

if (isset($_GET['format'])) {

$Report->Type = $_GET['format'];

}

$Report->Columns = array("Employee", "Department", "Salary");

foreach ($Employees as $Employee) {

$Report->Rows[] = array($Employee->Name, $Employee->Department, $Employee->Salary);

}

$Report->Display();

Recently, I have been tasked having to generate several reports containing various metrics, and then export these into an Excel sheet so that the data can be processed further. I also occasionally get requests for data in a CSV format that can be imported into another system. And these are just for the one-off reports... most of the standard reporting tools I have written produce data in an XML format, which is then procssed by an AJAX frontend and displayed in an HTML table to the user. Talk about messy.
So this morning, I finally sat down and wrote out a report abstraction class that has been floating around in my head for the past couple of months. Rather than have to worry about writing display code when building a report, I can simply deal with the data and hand it over to the class for display processing:

$Report = new Report( "My Report" );

if (isset($_GET['format'])) {

                 $Report->Type = $_GET['format'];

        }

$Report->Columns = array("Employee", "Department", "Salary");

        foreach ($Employees as $Employee) {

                $Report->Rows[] = array($Employee->Name, $Employee->Department, $Employee->Salary);

        }

$Report->Display();

From there, the class takes the type identifier (which in this case is being selected by the user and passed in the URL), and provides the data in the correct format. The class itself is fairly small, weighing in with less than 200 lines of code, but can display data in Excel, CSV, XML, HTML, or PDF, as well as a printer-optimized layout if the data is intended to be printed instead of displayed on-screen.