For a long time in the tech industry, the term “feature” has been used in a limited way, in my opinion, causing it to mislead people. Of course, software and hardware makers like it this way.

Even with a feature as simple as “track skip”, we can be fooled. Both product A and B list it as a feature, so you remove that feature from your comparison and move on to the next feature. Check, check, check. After discovering that both have all the same features by the reckoning of the feature matrix, you are down to price, and pick product B since it’s cheaper. With everything else being “equal”, you “wisely” choose the cheaper one. Except, product B is terrible. The build quality is worse, the ergonomics of the controls are terrible, and it is really hard to use the “track skip” feature that you thought was equivalent.

It turns out that what we have been calling features are really just simple items on a specs sheet, and they say very little about quality or user experience. We do this because it’s easier to regurgitate the speeds and capacities of the device components rather than to come up with a metric to compare the complex combination. For geeks, it’s often just about one-upping other geeks with a particular new feature while secretly suffering with usability.

Here’s an example from Rick Munarriz writing for The Motley Fool:

We know that next year’s shiny new iPhone will be better. It will feature a new design, be more powerful, and likely come with several features already found in Android phones, including 4G LTE connectivity and NFC chips for mobile transactions.

Yes, there are already phones with “4G LTE”, but it is known that, currently, the chipsets are larger and drain a battery very quickly making for a larger phone to house a larger battery as well as the larger chipset. My point is that when Apple puts LTE in the iPhone, the “feature” will be “LTE with a good user experience” which means good battery life without bulkiness. The attitude of the Android fans seems to be a “first post” one here. First, yes, but not a very great post.

Almost all the time, any new technology will not be well refined at first, so the user experience will be poor. The problem with many tech gadgets is that before the once-new feature matures to have a good user experience, the temptation to replace it with the next new one with a poor user experience is too great, and so they never have a refined product.

Clayton Morris talked about the RIM Playbook tablet and said:

… no one doubts that BlackBerry-maker Research in Motion can build a killer business tablet — but for some reason the company hasn’t.

Why do people somehow think that RIM has this capability simply because of the success of the Blackberry. Why did the Blackberry succeed? email. They built a smartphone that did it well for the time, and lots of people who needed good mobile email snapped it up. That’s it. RIM needs to have a new trick now, and it seems that, the Playbook is not it.

Of course, many reviews focus on the absence of mail, contacts and calendar apps. The reasoning for their absence is that you get them when paired with a Blackberry phone, which keeps that data secure on the phone. Really? No caching? When the Blackberry is out of range, the data is wiped, and reloaded when it comes back into range? This excuse quickly falls apart when we learn that these apps are coming to the Playbook later on. I think the real reason is that RIM hasn’t fully debugged the syncing of that data when there could be more than just your Blackberry phone changing data between syncs.

The Rise of the Personal Computer

Way back, the mainframe used to be your “cloud”. You could access it from a number of places and work on the same data, but with it time-shared so much or that the company never upgraded it because it cost so much to run, it was often slow.

The PC became popular because an affordable got powerful enough that since it gave all of its attention to you, it was faster. However, the “cloud” was gone (and so were the computer maintenance people, which was good and bad). Unless your data fit on a disk, you couldn’t access it from anywhere.

The Rise Of Laptops

We started to do more on our desktop computers, and we sometimes wanted to or needed to get out of the house. Laptops became popular. They also solved the problem of making our data portable, or rather they dodged it by simply taking your data with you. This is why laptops had to be powerful. They had become your main computer. They had become big, heavy and hot on your lap, and they soon were back on your desktop.

The Rise Of Mobile

Our laptops were not very nimble, and with the Internet, we’d come to do so much on our computer that breaking out tasks to other devices was compelling. PDAs were okay, but their merger with the cell phone gave them the magic of Internet access. The iPhone made them easy to use.

Then we came to do many things on our phone computers and less on our desktop computers. This was partly because many things were a better fit for a mobile device. The laptop could cover some of it, but not all of it well since it was bulky and had limited battery life. Having a to do app on your desktop was minimally useful, having it on your laptop was mildly useful, but having it in your hand was very useful. A to do app on an Internet connected smartphone that stays in sync with your desktop and laptop is even better.

The iPad arrived to skepticism, mostly as to what you would do with it. We already had desktop and laptop computers for big jobs or “getting real work done” (image of submitting a large stack of punch cards to a mini-computer to run some scientific calculation), and the “tablet computer” had failed several years ago. Why would we want a new computer that was less powerful than what we had?

Options

It turns out there is a use for it. You were using a laptop before, but it didn’t sit comfortably in your lap for extended periods or didn’t balance nicely on the arm of the chair. For a number of people, they moved some of what they were doing on the computer and some of what they were doing on the phone to the iPad. Not everything.

Originally, you didn’t have the option. You only had the desktop computer to do all your computing tasks. Then you got the laptop, and you had an option to do some with a portable computer. Then you got the smart phone, and you had an option to do some things on that. Some things were a little ridiculous to do on a phone, but you didn’t have any other option unless you had your laptop with you. The chance of having a given device with you is inversely proportional to its size and directly proportional to its utility, so it’s natural to do many things on your phone since it’s nearly always with you even if the device isn’t ideal for some of those things.

Once you have the option of the iPad, you can move some of those tasks to it that are not well suited to the phone, but are annoying to do on the laptop. Some things moved, but other stuff was accessed additionally on the iPad because of desktop sync and cloud sync. The iPad became just another view of your data.

Since it is not nearly as cramped as an iPhone screen, it is much more practical to work on your data, whereas the iPhone is well-suited to gather it, check it off or look at it. The thing is, that’s the sort of thing you used to do on your desktop. Now, unless its a big organization job, it’s more appealing to do it on the iPad now that you have the option.

The reality is that we didn’t need to do all these things on our desktop computer, it’s just that we didn’t have the option before. It’s like how email added another way to send messages to people. Of course, it was going to reduce the number of letters posted and phone calls made, simply because it is a more natural way for many of the messages to be sent, whereas before your only option was to send a letter or call. SMS did the same thing.

Full Circle

It’s clear that the idea from several years ago that we’d have a server computer on our network someday wasn’t completely wrong. It assumed that you’d get this big iron, probably in a rack in a closet and it would serve up stuff to your several machines in the house.

Well, it turns out that server is your current desktop computer. The clients are your iPhones, iPads and Apple TVs. The personal computer that started out as the thing to free you from the central (corporate) mainframe has now, itself become the central machine and the new mobile computers give us our freedom. With so much of the usual activity moving to the mobile devices, the big desktop has more free cycles these days.

It seems the desktop is getting much less love these days for me. Maybe it feels like those mainframes once people started getting PCs. I know that some people live on their laptops, but then I do my day job on a different computer than home. I have a laptop too, but it mostly sits there waiting for me to charge it up again. I would certainly use the desktop less than I do if it weren’t for the iPad being shared amongst the family.

I have been working on a custom CSS stylesheet for my Markdown conversions to HTML that just gives things a bit more style than the plain HTML, but not the overkill that most stylesheets seem to.

The problem was that when knocking up Markdown docs on my iPhone or iPad, the basic converters on the Markdown-savvy editors don’t have such a feature. So I wondered if I could do it some way.

I use nvALT on my Mac which makes .txt files in a folder in my Dropbox sync folder. I then use one of several iOS apps that sync with Dropbox to edit or create them on the go. If I create them there, I use the .txt extension.

One of the apps, Nocs makes it easy to convert a Markdown file to HTML, saving it back to the same Dropbox folder as the Markdown file. Fine, but again, no custom conversion. However, I realized that this HTML file would sync back to my Mac and (the first time at least) this would be a new file in the folder, which is just the job for Folder Actions!

I fired up Automator and said to make a new Folder Action. At the top of your empty workflow is a dropdown to choose what folder to watch for files added. Select the folder in your Dropbox sync where your Markdown files you want to watch are kept.

Now add one step to the workflow of “Run Shell Script” that youll find on the left under the Automator actions section. Replace the contents with the following script:

# When a new file is seen in the folder, this is run. If it is a .html
# file, that is taken as a signal that I want to create an HTML
# version of a Markdown document in this folder.
# This script re-does the conversion with my custom command. 
# Dropbox will sync this new version back to be available where I was working. 

# It uses the value of the md_ext variable to assume the name of the 
# original Markdown source file to re-convert, so you need to set that.
# Since I use this for Notational Velocity, that is set to "txt".

md_ext=txt

# Pick up most of the other PATH that is not set when executing in Automator.
# Even if we use full paths to things, markdown2pdf calls pandoc and pdflatex, 
# relying on the path to find them. You may need to additionally source other 
# files, or you may not need to do this depending on what tool you use.
# I'm using pandoc and markdown2pdf installed with MacPorts, so I have to
# do this.

if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`
fi
source ~/.bash_profile

# For all files added (don't know if Folder Actions sends several at once or not)

for f in "$@"
do
    ext=${f##*.}
    if [ "${ext}" == "html" ]
    then
        f_base=${f%.*}
        md_file=${f_base}.${md_ext}

        pandoc -s --css="http://home.comcast.net/~ryangray/markdown.css" --output="${f}" "${md_file}"
        markdown2pdf --variable=fontsize:11pt --output="${f_base}.pdf" "${md_file}"

        md_name=${md_file##*/}
        growlnotify -m "Converted Markdown to HTML and PDF" -t "${md_name}"
    fi
done

As a bonus, I added conversion to PDF as well. So both will sync back to Dropbox and then back to my iPhone or iPad. So, basically, a few seconds after I tell Nocs to save the HTML version, the customized HTML and PDF show up in its Dropbox file list.

Obviously, you would use whatever custom Markdown conversion you want, following my example here. I put my custom stylesheet on my Comcast site so that it can be reached wherever I’m viewing the HTML. I think I can have Pandoc embed it instead to make them truly stand-alone, but haven’t tried that. The Growl notification when it’s done is optional but handy for testing since the Dropbox sync may take a few seconds , the script may take a few seconds to trigger, and the conversion to PDF can take a bit as well.

The one extra step is if you are converting the same Markdown file for a second time or there’s already a .html version of it in the same folder you

You are welcome to copy my CSS file. It has things to support Pandoc and MultiMarkdown in that they use different class names for things. It also has some different treatments for printing built-in like using wrapping in the code boxes versus a scroll bar when on-screen. I’m going to try to put it up on github so people can track updates to it. Stay tuned.

http://news.cnet.com/8301-1001_3-20026607-92.html?part=rss&subj=news&tag=2547...

But come January, they're really going to do it this time. For reals. No fingers crossed behind the back. Both barrels blazing. Microsoft is going to save us from the monopolistic tyrannical walled garden of the iPad. Or was that Chrome OS? I'm confused. Seems the only real iPad competition that shipped I can recall was Android based.

So, given the arguments I've heard, iOS is only a mobile OS (it runs on the iPhone if you recall), therefore, the iPad is a mobile device and not a "true" tablet because a real tablet runs a real OS so it can do "real work". Makes perfect sense right? Is this perhaps why Chrome OS is not for mobile devices? If it were for both, the argument that iOS is not a real tablet OS because it also runs on a phone would not hold up as well. Also seems to explain why Microsoft is apparently not going to use Windows Phone 7 for the tablets as that would also undermine the story that tablets need a real OS for real work.

I came across a site, dashkards, that has some handy keyboard reference cards for Mac OS X’s Dashboard. They are done as Webclips. Of interest here are their cards for Markdown and Notational Velocity.

However, I was having trouble with installing more than one of these at a time — the last one would show, but the others would be blank.

Update: The dashkards site gives help on a workaround for this bug in Dashboard here.

I found another workaround:

1. Save the card’s webpage as a WebArchive from Safari
   You’ll want to keep the file around, so maybe make a folder for these.
2. Open the .webarchive file in Safari
3. Follow the original instructions for making the Webclip:
   1. Choose “File->Open in Dashboard…” from Safari’s menu
   2. Click on the card so it is selected.
   3. Click the “Add” button.

Since these are made from local pages, they won’t update if the dashkards site updates them, so that’s the downside of this workaround, but then since they are local, they should load faster.

I had been using the Mac OS X Quicklook generator for Markdown by Phil Toland, but I came upon a fork of his code by Michael Dominic K. that I like better. By now the fork largely has no purpose since Phil’s code now uses the discount C library too, but I like MDK’s .css file better since it is minimal. The nice thing with a Quicklook plugin is that it gets Spotlight to index the .md (or .markdown, etc.) files so the content is searchable. I did notice that MDK’s doesn’t include the .text extension, and I can’t figure out how to activate it. Maybe I’ll try to replace the .css file of Phil’s version.

So, to have a nifty way to preview any text you’re writing in Markdown on OS X 10.6, you can create a text service using Automator. For now, we’re going to assume you have a working installation of a command line Markdown to HTML converter. In this example we will use MultiMarkdown, but as long as you know how to use yours from the command line, you should be able to modify it to your needs.

This is really just mostly the first Automator workflow step from my previous post about making a service to be able to compose with Markdown in Mac OS X Mail.

To make this Automator service:

1. Open Automator

2. Choose to create a Service

3. Set the initial options:

   • Service receives selected text in any application
   • Uncheck “Replaces selected text”

4. From the Actions library on the left, select “Automator” to see its actions.

5. Select the “Run Shell Script” action and drag it to the workflow area or just double-click it.

6. Replace the sample command “cat” with:

   ~/Library/Application\ Support/MultiMarkdown/bin/MultiMarkdown.pl > /tmp/tmp.html
    open -a Safari /tmp/tmp.html

If you have the original Markdown installed, you will need to obviously change the path name to reference it instead, such as:

• /Library/Application\ Support/MultiMarkdown/bin/MultiMarkdown.pl

or maybe

• ~/bin/Markdown.pl

The full path is needed since (I think) the script will run in a non-interactive shell, which may not have all the $PATH directories that your interactive shell sets up depending on which profile script you do that in.

You could also add SmartyPants to the mix with:

~/Library/Application\ Support/MultiMarkdown/bin/MultiMarkdown.pl | ~/Library/Application\ Support/MultiMarkdown/bin/SmartyPants.pl -2 > /tmp/tmp.html
    open -a Safari /tmp/tmp.html

I have recently been delving into the world of Markdown, an easy lightweight markup syntax, mostly geared for writing for the Web. One popular Markdown app for iOS is Markdown Mail. I wondered how I could hack together a way to compose an email in Markdown and have it turned into HTML to send.

I started to make an OS X text service with Automator. The idea is that you select some text, then go to the services menu under the application’s menu or on the context (right-click) menu of the text. You select your service, it runs and usually is set to replace the selected text with its output.

The problem I encountered was that you can’t replace the text selection object — formatting and all — with the result of such a service. The plain text of the selection is sent to the service workflow, and plaintext is extracted from the result and that replaces the text characters of the selection, but not their format. I needed to be able to replace the selection with an HTML clipping rather than the HTML text that the Markdown converter generates. This is fine if you are in a text editor and are going to compose an HTML post or file by writing in Markdown, then selecting all and converting it to HTML text. You can see how to make this service in this nice post by Matt Gibson.

There might be some other way, but for now what I had to do was to save the HTML generated from the Markdown conversion to a temporary file, then open that in Safari, have Safari select all and copy to the clipboard (copying an HTML object), then having Mail paste it – replacing the selected Markdown text. So, the service workflow takes the selected text, but does not itself replace the selection directly.

To make this Automator service:

1. Open Automator

2. Choose to create a Service

3. Set the initial options:

   • Service receives selected text in Mail
   • Uncheck “Replaces selected text”

4. From the Actions library on the left, select “Automator” to see its actions.

5. Select the “Run Shell Script” action and drag it to the workflow area or just double-click it.

6. Replace the sample command “cat” with:

   ~/Library/Application\ Support/MultiMarkdown/bin/MultiMarkdown.pl > /tmp/tmp.html
    open -a Safari /tmp/tmp.html

   [Update]: I used MultiMarkdown in this example, but you could replace that with the command you prefer: the original Markdown.pl or pandoc along with your favorite command parameters for it. The thing to remember is that shell scripts in Automator don’t run with the same full path your regular Terminal shell does, so you usually need to give the full path to the executable. See also this other post of mine about Pandoc’s markdown2pdf.

7. From the Automator actions list on the left, add a “Run Applescript” step to the workflow.

8. In the script box, place this Applescript code:

   on run {input, parameters}
        tell application "Safari"
            activate
            tell application "System Events"
                keystroke "a" using {command down}
                keystroke "c" using {command down}
                keystroke "w" using {command down}
            end tell
        end tell
        tell application "Mail"
            activate
            tell application "System Events" to keystroke "v" using {command down}
        end tell
        return input
    end run

9. Save the workflow as, for example, “Markdown to HTML Mail”.

Now, compose a new message in Mail, typing in Markdown. Then select all and either right-click on the text and go to the Services sub-menu or go to the Mail application menu and the Services sub-menu from there. You should find “Markdown to HTML Mail” there, and after selecting it, and a flash of action, your Markdown text has been replaced with rendered HTML. You can always use undo if it didn’t come out well, so you might want to use a variation of this service to have a Markdown preview to check on things until you are finished. That’s in the next post.