Monday, July 16, 2012

Twitter Alternatives (Rough Draft)

The beauty of Twitter is that it's simply 140 characters of text. Shorter than an SMS text message - akin to a headline. Any other payload in the message is a hyperlink which is also text.

Why only 140 characters per tweet? Because it was designed to fit into a 160 character SMS message preceded by the sender's user name:
"@joemoreno: Just arrived at the Top of the Rock. http://epics3.com/piqk"

Which begs another question: Why only 160 charters for an SMS? Because the inventor of SMS, Friedhelm Hillebrand, typed out random sentences and noticed that they fit into 160 characters.

Worthy Competition
There have been some alternatives to Twitter, but they're just copies. What's the point of making a copy of Twitter if it still suffers from the same Achilles' heel: a centralized single point of failure controlled by one corporation?

A worthy competitor to Twitter requires fundamental integration into the Internet's infrastructure. This shouldn't be too difficult, after all, it's just text --- or another way to think about it, it's just TXT.

DNS? Seriously?
The Twitter alternative that I'm proposing simply uses DNS. In other words, a tweet would simply be stored as a DNS TXT record. Since it's widely recognized that DNS is the Internet's single point of failure, it has multiple, redundant and distributed, servers to keep it running. DNS servers have impeccable uptime stats because, without DNS we have no practical Internet connectivity.

Advantages.
1. No additional servers required. Simply add a new DNS record for each TXT tweet.

2. Redundantly propagated across multiple DNS servers.

3. Server load distributed to ISP DNS caches. In other words, massive traffic for a single tweet would not need to go back to the authoritative DNS server. Set a long TTL for the TXT tweet, say 24 or 48 hours, and each local ISP should only hit the authoritative DNS server once every day or two to refresh a particular tweet's TTL.

Disadvantages
1. Can't easily delete tweets since they're cached at each ISP's DNS server, especially if added with a long TTL.

2. Tweets would need to be inserted into TXT records using a robust API - the only one I'm aware of is Amazon's Route 53 API.

3. Each TXT tweet would need to be a linked list to the previous tweet; or, perhaps, a double linked list to both previous and next TXT tweet.

4. Each TXT tweet would need an embedded timestamp (either UNIX timestamp: 1342472514 or a human readable dateTime object: 2012-07-16T20:38:00Z).

5. TXT tweets, unlike Twitter tweets, can be edited.

6. TXT tweets can expire after the TTL timesout.

TXT Tweet Proposed Standard
The format of the TXT tweet uses pipe | delimited text:

Timestamp | GPS Encoding | TXT Tweet | Previous Chronological Tweet Host Name | Next Chronological Tweet Host Name (optional)

(White space added around pipes only for readability purposes.)

Since the TXT tweets are a single (or double) linked list, we need to know where to start. The logical place to start is with the most recent (i.e. last) TXT tweet. That could be defined in the domain's root TXT record which can be found via the dig command:

dig -t txt joemoreno.com
joemoreno.com.   1 IN TXT "2012-07-16T20:38:00Z|tweet4.joemoreno.com"

So, the most recent TXT tweet is at tweet4.joemoreno.com. (A simpler naming convention could be host names with integers, such as 0.joemoreno.com, 1.joemoreno.com, 2.joemoreno.com, etc.)

dig -t txt tweet4.joemoreno.com
tweet4.joemoreno.com. 86400 IN TXT "\"2012-07-16T20:38:00Z | 40\16150'16.8\"N74\16127'57.6\"W | 31 years ago, today, Harry Chapin left us. http://blog.joemoreno.com/2011/07/harry-chapin.html | tweet3.joemoreno.com |\""

TXT tweet tweet4.joemoreno.com points to tweet3.joemoreno.com as the previous TXT tweet.

dig -t txt tweet3.joemoreno.com
tweet3.joemoreno.com. 86400 IN TXT "2012-07-16T20:36:00Z | | Yahoo has named Google executive Marissa Mayer as its new CEO. | tweet2.joemoreno.com | tweet4.joemoreno.com"

Practically speaking, we might be limited to 254 characters in a DNS TXT record in order to support older DNS servers. It's a tight fit, but it works with the timestamp, GPS encoding, 160 character TXT tweet, plus the previous and/or next TXT tweet host name.

Left for the Student
Several services need to be built on top of this proposal. Displaying a single user's TXT tweets can be rendered by a simple script running on a web server to display a specific user's feed. Mixing different user feeds, chronologically, is a little harder, but very doable.

However, where it gets challenging is how to handle "follows" and "mentions." In both cases, a server would need to either push or pull these notifications in real time. Pulling could be simple polling, like an RSS feed query. But, push notifications can be a bit more challenging. I'll have to think about how this part would work.

Sunday, July 8, 2012

Time Management in the 21st Century


The primary purpose for planning is to get results by controlling events.

Over the years, I've learned how to plan to forget everything that I need to do and organize in a way so that I could afford to forget.

The key is to organize my tasks so they are either self-prioritizing (we never forget to wear our shoes to work) or ensure that they come in front of me at the appropriate time. This seemingly simple advice took me a long time to master. But, now that it's a habit that makes for relaxing evenings since I can free my mind from work. 

Que Sera, Sera

I come from a rather casual family. I like to use the term, "Neapolitan," to describe my New York Italian upbringing. In simple terms, this means that my family was always late to events, or, rather, we considered 90 minutes late to be on time.

When I was 18 years old I joined the Marines. The Marine Corps obviously had a different philosophy about timeliness and tardiness. Being late was a crime known as UA (AWOL). "Hurry up and wait," was the norm as well as other axioms such as, "To err is human; to forgive is divine. Neither of which is Marine Corps policy."

Two events from my time as a Marine helped me refine my time management skills.

Write It Down

When I was a corporal, we were getting ready to make an amphibious landing, during an exercise, after spending two weeks aboard ship.

Technical aside: We were testing out new military equipment which we could use to set up simple, secure, chatrooms. It was nothing more than a specialized piece of hardware that could interface with an encrypted military radio system (PRC-77 and KY-57) using Procomm software that was very popular in the pre-TCP/IP world of the mid-1980s.

While preparing for our amphibious assault, I had packed up the equipment and then, unbeknownst to me, another Marine had placed it on a chair and slid it under the desk to tidy up our workspace. Instead of making a list of materiel to bring ashore, I just glanced around the desk and saw that there was no visible equipment - I completely missed the fact that the laptop and communications equipment were tucked under the desk on the chair.

When we got ashore and discovered that the comm gear was missing I received a nice reaming from my captain.

Lesson #1: Write it down.

Plan It Out

About seven years later, when I was a first lieutenant, I was deployed with a MEU made up of four ships sailing for the Persian Gulf. While in the middle of the Pacific Ocean, I was supervising the transfer of supplies from one ship to another - known as cross-decking. To make a long story short, the supplies didn't get palletized in time to make the scheduled helicopter.

Lesson #2: Plan It Out.

Get Results

As a Marine supply officer I was responsible for ensuring that we tracked all of the equipment in our battalion - after all, it was entrusted to us by the U.S. tax payer. This process was accomplished using a cryptically named procedure referred to as the quarterly CMR reconciliation.

Since I, working in the supply warehouse, didn't have day to day control over, say, the rifles in the armory or the Humvees in the motor pool, we'd ensure that these items were tracked by a specific person, designated in writing, known as the Responsible Officer (RO). We had about a dozen CMR accounts in our battalion and, once a quarter, we'd task the RO to physically inventory each item within 15 calendar days as per the Marine Corps Order (at the time, deadline extensions were not allowed).

The problem is, even with the ROs best intentions to complete the inventory, on time, the CMRs were rarely completed by many ROs within 15 days for a host of legitimate reasons. Although this wasn't my responsibility, it would always come back to bite me, later, when our records were inspected annually.

I tried a variety of techniques to improve this process. One option was to have the RO sign a letter of intent that the inventory would be completed within 15 days. But, when the CMR still wasn't done on time (again, usually due to circumstances beyond our control) I was stuck with the same "ding" on our inspection. Another option was to get the CO or XO involved in the process, each quarter, but that still didn't work.

Of course, we could have backdated the CMRs - formally known as fraud - but we never did that. I'd rather take the hit on the inspection.

After trying a host of different techniques, we finally found one that worked. Instead of issuing out all CMRs to all the ROs at the same time, we'd meet with each RO, before the beginning of each quarter, to see when he wanted to conduct his inventory. This definitely made our job, in the supply section, harder since we had to track a dozen different CMR deadlines, but that's what it took to get the job done. We put up a large white board in our office so we could easily see the status of each CMR. Problem solved.

Lesson #3: Get results.

Time Management in the 20th Century

After my mistake, when I was supervising the pallet cross decking, I became intrigued with time management. I needed to find a way to better track tasks. I tried different techniques and studied time management books ranging from Time Management for Dummies to Stephen Covey's The Seven Habits of Highly Effective People and First Things First. Many of these teachings focused on the four generations of time management.

The key that I discovered in the mid 1990s was to carry a day planner with me, all the time, and write down every task and appointment. I wouldn't check off a task until I had confirmed that it had been completed. Any to-do item that didn't get done today was moved forward to the next day's list in my day planner. After a few days of rewriting low priority tasks, I either got it done or explicitly dropped that to-do since it was no longer important. I didn't prioritize to-dos with letters or numbers, such as A, B, or C - that just doesn't work on paper. If there was something on my list that was urgent or important, I simply highlighted it with a yellow highlighter.

I photocopied important lists - such as a list of all the equipment in our infantry battalion or a list of the supply chain status codes, etc - and added them to my day planner so that they were always at my finger tips.

Any task that I wrote down in my day planner, which needed to be delegated, was prefaced by my coworker's name:
☐ Sgt Smith - Complete maintenance report and fax to HQ.

As I delegated the task Sgt. Smith and I would agree on the deadline and then I'd add that to the task in my day planner:
☐ Sgt Smith - Complete maintenance report and fax to HQ. By Thursday close of business.

I ended up turning my time management techniques into a 74 page workbook that I used to train others.

All of these techniques worked fine until the consumerization of IT resulting in the proliferation of personal smart phones and tablets in the workplace. Carrying around a day planner was no longer practical.

Welcome to the Digital World

While the fundamentals of the time management skills I learned haven't changed, the implementation is much easier in the digital world. No more carrying around a paper based day planner or writing and rewriting tasks on paper.

Over the past year, I've learned how to simply use my iPhone, iPad, and Mac to easily manage my time and tasks via iCloud. You don't need all of these devices and services - just an iPad, alone, will suffice - but I found it very convenient to have it all tied together and kept in sync. However, if you're not disciplined enough to follow my first lesson - write it down - then it won't work.

Meetings and Appointments

Keeping track of meetings and appointments is much simpler, now, since you'll probably be notified of an upcoming meeting, via e-mail, with either an Exchange or iCal invitation. As a matter of fact, you probably won't even see the e-mail with the calendar attachment; instead your device will automatically place the meeting invitation on your calendar where you can answer Yes / No / Maybe.

One gotcha when using iOS devices in a Microsoft Exchange environment is that, occasionally, if you accept a meeting on Windows it might not show up on your iOS device. The key to preventing this is to only accept meetings on your iOS devices. If you accidentally accept a meeting on your Windows computer and it doesn't show up on your iOS device, then you can forward the meeting from Outlook, to yourself, as an iCal invitation. The iCal and Exchange meeting invite won't be in sync if the meeting time changes, but it's better than completely forgetting about the meeting.

To-Do Tasks

Every time you come up with a new to-do task then write it down in your device. Since iCloud syncs everything for you - usually within seconds - then it doesn't matter where you write it down since it'll show up on all of your devices and computers.

I use iOS's free Reminders app which is a simple way to track a list of tasks. I've labeled one list "Me," which are tasks that I need to complete. I've also created a list for each person that I interact with on a daily basis. As to-do tasks come up that I need to delegate, I write them down on that person's list. Now, whenever I'm talking to that person, I can just look at the person's to-do list in my Reminders app.

The key, when jotting down tasks for delegation, is to write out the to-do reminder as you'd actually ask it. For example, if you only write down "Report" then there's a good chance that you'll forget which report, etc, you were going to ask about. It's better to write down as much detail as possible; for example, "What is the status of the maintenance report that's due to the COO tomorrow afternoon?"

After each tasking that isn't fully completed, I put an "A:" and jot down the "answer" to the question I asked or its status. That way, when we reviewed it later we could pick up from where we left off.

Notes and Minutes

Over the years I've sat in some long meetings and conference calls. It's impossible to remember every decision, tasking, issue, and due date from every meeting. I've found it very handy to capture all of this information in the iOS Notes app. This is especially handy since it's searchable. I generally create a separate note for each project where I can track key events and decisions. Many times, project information will be passed via e-mail, so it's simple to copy and paste it directly into the respective note. When deadlines changes, it helps to explicitly capture that, too.

7/9: Code complete (was 7/1)
7/10-18: User acceptance testing (was 7/6)
7/19: QA begins
7/20-21:Vulnerability assessment scan
7/24: QA complete
7/25: QA sign off
8/1: New website live

Remember, to have a fighting chance, you'll need to get into the habit of always writing down all of your tasks.

Tuesday, July 3, 2012

Blogging vs Journalism

Journalism, meet blogging:
Writing a personal blog post on 5/20/12 that CNN reported on.
What's the difference between blogging and journalism?

There's a perception that journalists tend to look down on bloggers since the bar to blog is low. Anyone can become a blogger - simply set up a free blog and write whatever you please. If you blog on a semi-regular basis then, congratulations, you're now, officially, a bona fide blogger.

Journalists, on the other hand, tend to be paid professionals - backed by a corporation with proofreaders and fact-checkers - whereas all but a few bloggers do it pro bono (or receive a trivial amount of incidental ad revenue).

Key Difference
I, having been both a paid and unpaid journalist and blogger, noticed one key difference between blogging and journalism...

Journalist tend to report the facts and interview (quote) witnesses. To put a fine point on it, journalists report what witnesses say.

Bloggers, on the other hand, tend to write essays from their personal point of view. Many times, if a blogger does quote a witness, the witness was probably not speaking directly to the author (i.e. the blogger heard the quote on T.V. or Twitter, etc.)

(Side note: Is this the future of reporting, complete with witness citations?)

Bloggers tend to write in first (I) or second (you) person. Journalist tend to write in third person with first hand quotes from witnesses.

These key differences are not hard and fast rules, they're simply generalizations.

Let's look at it a different way. How many blog posts have quotes from multiple first hand witnesses expressing different opinions? Not many.

Just to be clear, I am, in no way, favoring journalism over blogging, or vice versa; rather, I'm simply pointing out a key difference between the two.

Purpose
Rather than debate whether journalism is more important than blogging, it's best to realize that each serve a different purpose.

The purpose of journalism is to report the facts and record events for a (daily) historic purpose. Many regularly scheduled publications are official newspapers of record - in other words, a private or public company authorized by the government to publish public or legal notices. (Conversely, I am not aware of any "blog of record" which serves this purpose.)

While blogs can have many different purposes, their best use, as Dave Winer has described for more than a decade, is to "Narrate your work." You can think of blogs as both professional diaries for discussion and debate as well as a place for describing personal experiences.

Neither a single news article can define journalism nor a single post define blogging. Rather, it's left as an exercise for the reader.

Tuesday, June 26, 2012

Bread and Water

When I was a Midshipman at the Naval Academy I took a Law for the Junior Officer course. It covered the procedures, processes, and punishments of military law and the UCMJ.

Our instructor was a JAG Navy commander. He earned a Bronze Star during Desert Storm by monitoring radio networks and preventing a fratricide incident in the heat of battle.

He taught us a great lesson in creativity that he learned when he was a legal advisor to an aircraft carrier captain.

A Navy ship's captain, who is the commanding officer of the ship, can hold legal proceedings and dish out punishment. One punishment that's still on the books in the U.S. Navy is bread and water. To receive this punishment, a prisoner's first certified as healthy by the ship's doctor before confined to the brig.

My law professor told us that the bread and water punishment didn't work out as well as expected. The delinquents ended up bragging, after their incarceration, about how they survived the "old man's" most severe punishment allowed by law. Instead of a punishment, it became a point of pride.

What to do?

My professor had his ship's legal team take a closer look at the bread and water regulation:

(A) if imposed upon a person attached to or embarked in a vessel, confinement on bread and water or diminished rations for not more than three consecutive days;

A light bulb went off when they read, "diminished rations." Instead of serving bread and water, the prisoner was now fed baby food. Same caloric content, just a different medium.

Telling shipmates they survived three days on baby food ended the bravado.

Author: Joe Moreno

Monday, June 25, 2012

My Early Days At Apple

In the late 1990s, when I told people that I worked at Apple, it was like telling them that I worked at Atari or Commodore. "You don't hear much from Apple, anymore," someone once said to me.

The funny part, when I started working there in 1998, was that I had no experience on a Mac. I only knew that Macs were easy to use. I was hired at a job conference in San Diego and, after I accepted the verbal offer, I confessed to my soon-to-be boss that I had never worked on a Mac. "Don't worry about that - we use Windows NT," he said.

Seriously? I was about to go work for Apple on Windows?!?

I shouldn't have been hired due to my lack of web/Java experience, but it was the Dot-com boom and Apple was hiring like Gang Busters. I didn't even know what my job position would be when I signed up, so I was wondering what I'd be working on that required me to relocate to the Washington DC area. All I knew is that it was an unbelievably exciting time to be working in high tech. It seemed like everyone was getting rich!

It turns out that I was hired to be a WebObjects consulting engineer for the consulting division in the Apple Federal office (this office has since relocated to a different part of town).

Why Windows?
My first week at Apple, I was given a Toshiba Tecra and my job was to "build it from scratch" which meant installing Windows NT, WebObjects, and an Oracle database server. This was not an easy task - I had to hunt down lots of little things like network card, video, and printer drivers and then figure out which interrupts they needed to be configured to (if I recall correctly). But, before I did that, I had to use a floppy disk to install PKZIP so I could unzip files. Not fun at all. I felt so dumb that I'd be sure to ask different coworkers for help so that no one person could see my total ignorance.

The reason we worked on Windows NT was because, the previous year, Apple had purchased NeXT for both their operating system (OpenStep) and web app server (WebObjects). At the time of the purchase OpenStep and WebObjects ran on Windows NT.

Several years earlier, NeXT engineers had ported NeXT OS from their proprietary hardware over to Windows - a technique that would benefit Apple in 2005 when they seamlessly ported Mac OS X from the PowerPC to the Intel processor. Their secret was to develop against layers of abstraction rather than hard coding directly to low level hardware. For example, to get WebObjects, which was designed to run on UNIX with a Mach kernel, to run on Windows NT, they ported over a subset of the Mach kernel to sit between WebObjects and Windows. It ran as a Windows daemon to help WebObjects work with Windows.

Apple's Future
Apple's future was very precarious in the late 1990s. During my first few years, I kept wondering why I was purchasing Apple stock and not Microsoft's. The iPod, iPhone, and iPad weren't even a gleam in Steve Jobs's eye back then as he attempted to design four desktop and laptop computers for the consumer and professional markets.

While a lot of my coworkers had jumped ship in the late 1990s I hesitantly decided to stick it out. I had seen a glimpse, through WebObjects and OpenStep, of what the future could be. Needless to say, it turned out much better than I could have imagined.

Looking back, it seems that Apple was predestined to become what it has - but, living through it was a daily ritual of self-doubt.

Saturday, June 23, 2012

All Servers Die So Take Care of Your Customers


Adjix, Epics3, et al, server farm with two dead (vertical) servers.
Serving up nearly 100K unique visitors daily on 512 Kbps.
Adjix

I wish that I could say Adjix died peacefully, in its sleep, but it was a sudden, unexpected death as it went down fighting.

RIP Adjix.

New Year's Eve 2012
I received a call from a couple of key users, on New Year's Eve afternoon, that my beloved Adjix was having problems. After the calls, I discovered that the Adjix database had unexpectedly stopped and needed to be restarted. We knew that the Adjix database didn't have much life left after the San Diego power outage of September 8, 2011 knocked out some servers in the cluster - but I wanted to keep Adjix running until the last possible moment.

After identifying the problem, during the afternoon of New Year's Eve, I restarted the database server and I could tell that it would take several hours to rebuild the indices and check the database integrity due to its large size. After all, you do want your database to be ACID compliant.

Then, ominously, just before midnight EST, the physical database server (hardware) stopped responding to any and all commands.

Today, six months later, I gained physical access to that server - the last one in that dying cluster - and this is the final entry from the logs (-0800 is PST).

2011-12-31 21:52:43 -0800: Rolling forward master [80.1% complete] 17154000 SQL transactions processed

Sure enough, the logs confirmed that, with less than eight minutes left before the New Year, the hardware stopped responding.

Future Proof
Although I never charged anyone to use the Adjix APIs, I still felt that everything I delivered should be future proof.

In theory, we can see that Adjix links redundantly work as expected:

http://adjix.com/ai26

But, I have to admit that I'm amazed to see, six months after Adjix died, that others' Adjix links are still alive and kicking:
http://twitter.com/search/adjix

(Note: ad.vu is the ultra-short version of adjix.com.)

Not only did Adjix automatically store every single shortened URL in its own adjix.com Amazon S3 bucket, but Adjix also gave every user the opportunity to store the Adjix shortened link in their own S3 bucket.

Applying Lessons Learned
In early 2010, I launched a photo sharing service, Epics3, which allowed users to share photos on Twitter and Facebook as well as store any photo they uploaded to their own Amazon S3 bucket. Just like Adjix, this was a simple solution to implement resulting in two separately owned and operated servers redundantly serving up the same content.

As an example, the first of the following links is dynamically generated from the Epics3 server and the second one is served statically, directly, from an Amazon S3 bucket.

http://pics.joemoreno.com/2gi3

That, my friend, is future proofing. You'd think, after four years, that it would be more popular.

On New Year's Eve 2012, Adjix died. Long live Adjix (and all other customer data).

Friday, June 22, 2012

Mathematics Debate

It's been about three and a half years since I blogged a math problem, so I'm way overdue.

Today, at lunch, my wife, who's a middle school math teacher, and I had a discussion about numbers. I mentioned to her something that Dave Winer had brought to my attention, this past April:

Does 0.99999 = 1?

"No - of course they're not the same," is most everyone's initial thought. Those two numbers are close... but not equal.

But, try this proof:

Q: Does 0.33333 = 1/3?
A: Yes!

Ok, next question...

Q: Does 0.66666 = 2/3?
A: Yes, again!

So, now for the punchline:

Q: Does 1/3 + 2/3 = 1?
A: Well, yes. But...

The beauty of mathematics is even though it's an abstract field, it's a pure discipline unlike, say, computer science. The laws of mathematics are constant throughout the entire universe.

So, does does 0.99999 = 1? Unfortunately, there's no simple answer.

Tuesday, June 19, 2012

From Steve's Lips to an Engineer's Ears

At Apple, the engineers are the talent and "This doesn't suck too bad," was high praise when I worked there.

Initially, when I began working at Apple, I thought that the company was primarily about design on many levels - industrial design, UI design, system architecture design, software design, etc.

I was wrong.

Design was just a means to an end - and that end was to provide the best possible user experience (BPUX) - the UX of highest quality. It meant, for the time being, there was no better way to design the UI for a better UX.

Think of BPUX as the nirvana of customer service. This is why consumers love to do business with Apple instead of, say, the phone company.

Holistic BPUX includes everything, from making the purchase and opening the box to using the product and calling on tech support. Apple's focus is not about squeezing every possible dollar from the customer, in the short term, at the expense of long term profitability. Sure, Apple cares about making money, but that is not what they design for.

Apple clearly understands that, as a consumer electronics company, they are not selling technology products. Rather Apple is selling a user experience and, to the user, the interface is the product. Steve Jobs inherently understood this decades ago and he said it best at WWDC in 1997:

You got to start with the customer (user) experience and work backwards to the technology. You can't start with with the technology and try to figure out where you're going to try to sell it. And I've made this mistake probably more than anyone else in this room and I've got the scar tissue to prove it.

But, when evaluating user experience, you have to look at it holistically with "rigid flexibility."

The first generations of iPods used an Apple developed connectivity technology, called FireWire, instead of USB 1.0 because FireWire was about 30 times faster. When USB 2.0 became the de facto standard on PCs - with speeds comparable to FireWire - Apple transitioned their iPods away from their own FireWire technology to the USB industry standard.

Steve's Requirements
Steve obviously understood design, but how, exactly, does a requirement from Steve Jobs travel to an engineer? It's a rather simple process that involves neither formal documentation nor written approvals.

In 2006, we were redesigning the Apple Online Store. My boss's boss was in a meeting with Steve when Steve directed that, once customers were at the online store, they should be able to find any Apple product within three clicks. The three click requirement wasn't invented by Steve, but he knew that time and clicks were two basic quantitive metrics for measuring BPUX. (As a side note, in this same meeting, Steve mentioned that he disliked contextual menus - right click pop-up menus - because they had become a dumping ground for unimaginative and lazy UI designers.)

So, we, the engineers, were simply told that each Apple product had to be found within three clicks. That might sound simple until you run a search for, say, headphones which returns about 200 different products. You can't paginate the results into batches of 10 or 25 because that would result in more than three clicks. On the other hand, you can't display all 100 or 200 products at once because that would overload the servers. And, you most certainly can't tell Steve, "It can't be done."

What do you do?

Infinite Scrolling
A coworker implemented a solution, called "infinite scrolling," for which he won an internal Apple innovation award. Today, in 2012, we take infinite scrolling for granted, but, back in 2006, AJAX was a fairly new web development technique with its key technology specification having only been drafted that year.

Simply put, infinite scrolling is the experience we have when scrolling down our Facebook or Twitter web page (example). As we scroll down to the bottom of the page, more of the web page is dynamically loaded which satisfied Steve's three click requirement, in both the letter and spirit of his intent, since a scroll isn't a click.

At the Apple Online Store, we implemented infinite scrolling by caching the product search results and then we'd trickle the results to the user for rendering in their web browser as they scrolled down the web page.

True Empowerment
Infinite scrolling isn't really a big deal and today's Apple Online Store implementation is different than the one implemented in 2006 --- the key thing to note about Apple is that neither Steve, nor any other manager, tried to solution the implementation. Instead, they pushed the problem down to the lowest level possible - to the talent: the engineers.

Thursday, June 7, 2012

New Sandwich Shop, New Cash Register

This morning, my wife and I had breakfast at a new restaurant that just opened this morning. It's only a block away from our home and we'd pass by it frequently as they prepared for today's opening. We were the only customers in the restaurant since it was late in the morning when we went. But, we were told that business was moving along very nicely earlier in the morning.

When we bellied up to the counter to pay our bill, we couldn't help but notice that their cash register was an iPad connected to a cash till and credit card printer. They were excited to show off their high tech point-of-sale (POS) system which got me wondering if it was actually cheaper - in terms of total cost of ownership - than a traditional cash register.

Realistically, an alternative solution, like Square, seems practical when processing only credit cards on the go. A fixed POS system needs to securely store cash as well as process credit cards and it should be somewhat rugged.

A basic cash register, with a till, starts at about $200. Then add one or two hundred more for a printer and credit card swiper. On the other hand, a new iPad 2 (previous generation) starts at $399 plus the cash register app, printer and till will bump up the cost. A key benefit of an iPad POS is that it has more features and can collect more data than a basic cash register.

I still can't help but ponder how this will hold up. Even though most cash registers at retail chains are actually stripped down PCs which are networked into servers - I wonder if the iPad POS will work as expected or if it'll end up being more like a portable GPS system on your car's dashboard vice a navigation system built into your car. In other words, it's the difference between a dedicated tool for a specific job or, perhaps, a solution looking for a problem.

Of course, if the iPad POS was wirelessly connected to the kitchen - which I don't think it was - that would be a no brainer in terms of efficiency. But, regardless, the nicest benefit of a mom-and-pop shop using an iPad cash register is that they can take it home at the end of the day and use it for more proper iPad duties.

Friday, June 1, 2012

Pink Slipped on Pink Shirt Friday

Today was Pink Shirt Friday at work. I've known my boss/buddy for more than a dozen years and, about once a quarter, we coordinate wearing pink shirts to work on a given Friday. This week, we extended the invitation to all of the directors that work in the Product department.

The irony about today's Pink Shirt Friday is that pink slips were handed out and the entire Product department was dissolved. The layoffs - including me - were due to the fact that the Product department's original tasking had become obsolete. It's a shame because it seems like it was only yesterday when I wrote this piece.

In all actuality, it's very true that our departments's original tasking had become obsolete. Although I worked at Wyndham for only eight months, I noticed that the company had many processes and layers that could be streamlined. Slimming it down, by eliminating the Product department, will probably be a good thing. After all, lean processes are how we did it when I worked at Apple.

What Does the Product Department Do?
Generally, the Product department manages the product roadmap and it sits between Marketing and Engineering. But, it seems that our Marketing, Product, and IT departments ended up working so closely together that Marketing could deal directly with the engineers in many cases - especially once a project's requirements had been documented.

This video best describes the perception of the Product department.


Practically speaking, you can think of one duty of the Product department as a waiter/waitress who's filling a role between a restaurant customer and the kitchen.

It's About The People
In my short time at the company, I was part of a few key product launches that received a fair amount of attention including the Room Key joint venture and the mobile websites and apps launches.

The disappointing part is that I relocated from San Diego to the Greater NYC area for this job and it barley lasted eight months. But, I've been pleasantly surprised at just how much I enjoyed working with my fellow managers, directors, and VPs who are very thorough, smart, and hard working people.

It's not often that you work with a team of people who stay on task, no matter what, until the job is done; especially during the late night conference calls, like this one, where you end up hearing the birds chirping as you watch the sunrise before the call is over.

In the end, with the Product department no longer needed, all of the directors were given notice, today. And, although I'd seen many rounds of layoffs at Apple, this was a first for me. Fortunately, the company seems to have gone above and beyond and treated us well.


Oh, there's one other thing that I will certainly miss: Free Ice Cream Fridays.