- Mac/Yahoo Desktop Widget
- Cleanup of old files in codebase
- Consistent mail sending for messages other than broadcasts
- Firefox/Thunderbird Extension for showing message stats
- Refactoring message sending to show customers progress in sending and allow support team to ‘finish’ messages that get stuck
It’s a very sad day when the open-source community is forced to take a highly-successful, visible, driving project like Firefox and change its name to something like Iceweasel. By changing the name we lose invaluable branding and popularity for the Debian and other distributions that choose to make this distinction. This sort of decision is equivalent to a 3 year regression for Linux.
The name Iceweasel sounds like the odd name of an infant open-source project. Many people give up on Linux read names like Iceweasel and GIMP.
As mentioned previously, we’ve been enjoying our Ambient Orb at the office to show the number of new IntelliConact customers each day. A few weeks ago, one of the developers wanted to see the array of colors provided by the orb. “No problem,” I said, “I’ll just unplug it and you can see the cycling sequence.” I unplugged the orb, and it started cycling after a few minutes. Unfortunately, it never stopped. Long and short, the orb has bit the dust. Today I finally got around to emailing the support line over at Ambient Devices. I let them know that I had two orbs configured in the same way that one was working while the other was not. Within a few hours, I received a response including instructions on removing the circuitry from the orb, swapping out a PCB between the two, and confirming the problem was that suspected by the support team.
Here’s a copy of the email I received:
A screenshot from the instructions:
Clearly, Ambient Devices doesn’t believe in making excuses or defining hoops with RMA numbers and hoops for their customers to jump through. Rather, they sent me instructions on easily diagnosing the problem. As you can see the instructions are worded in a light-hearted way and take the fact that technology isn’t always perfect as the spice of life rather than the price of our connected world. Most importantly, they empower their customers to do exactly what’s necessary to fix their problem, however scary it might seem. Although not all our products involve few enough pieces to send a 3 page PDF to solve most customer issues, I think we must all remember that the customer often outwits us by finding problems we didn’t, finding uses of our products we’d never imagine. It’s always important to embrace the customer’s ingenuity and empower them to solve their own problems no matter. Sometimes it will take extra effort on our side to boil down our problem-solving strategy to a series of ‘teachable’ steps, but the reward of reduced calls and people blogging about the excellent service are probably worth it.
[tags]customer service, orb[/tags]
Hi, David. This is an interesting approach, but I think itâ€™s a solution to a slightly different problem than teaching someone PHP. Instead, itâ€™s a solution to teaching someone the basics of building a web app and you just happen to use PHP to teach those concepts. A perfectly worthwhile and desirable goal, but different.
I agree and disagree with some of the points Sklar (sorry, two David’s makes this confusing) goes on to make. If I may paraphrase, Sklar is raising a point which competes with that raised by Ben in our initial discussion. My initial suggestion in the discussion with Ben indicated that books should start by teaching PHP on the command-line and slowly build up to constructing a very lightweight MVC framework and example application. One of Ben’s chief, and valid, concerns equated selling books about PHP with convincing readers or page-flippers that the book would teach them to build web pages in the first few chapters. Or that individuals might be turned off if they weren’t creating XSS attacks willy-nilly by chapter 3. I think the counter to this that Sklar raised is that by hiding the framework you turn off the people who don’t feel they’re really getting their feet wet with PHP. They feel that by using your framework they aren’t learning the ‘real guts’ of the language.
This clearly relates directly to some of the arguments Sklar makes that other languages face this challenge as well, but PHP perhaps more so than others. PHP digs its own hole here because unlike a .NET, Java, or a ColdFusion, PHP has built its name on easy to learn and get going. You can pay $4.99/month and get a server running PHP in 10 minutes. Writing an application in any of these other platforms can take orders of magnitude longer to setup, there’s an expectation of barrier to entry for learning, and often you have to buy pieces of it like an IDE. Sklar indicates that it’s important to strike the balance between “a way to do things” and “the way to do things”.
The dilemma lies in choosing whether I ask the reader to take on faith that the framework underlying the first half of the book isn’t worth delving into right now, but is worth understanding later and either using the quick framework or garner enough knowledge of the principles to build your own. Or, do I go back to my original plan of introducing PHP on the command-line as we built up a small framework and graduate up to a web page far later in the book.
I have full confidence that either approach might work. I know universities teach Physics both with and without calculus to which I’m sure the physics professors initially said “you can’t teach physics without calculus, it’s heresy!” But, this day in age there’s only one physics. I know my economics professor told me she didn’t like math, but she managed to teach a great class about economics concepts by moving lines back and forth on graphs.
[tags]learning php, programming, computer science, php, php books[/tags]