It occured to me today that Google has given itself several competitive advantages that are based on either technologies that are *very* hard to duplicate well(speech recognition) or a content net spread very very wide (e.g. properties like Picasa, Finance, News, Mail, etc.).  

Speech recognition at Google is based on the cultivation on unimaginable piles of data retrieved from their short-lived GOOG411 project to search itself.  This data is gold and is completely unavailable to companies that need to but probably won't be able to compete in the voice recognition space (I'm looking at you Microsoft and Google).  That Google is pushing that advantage in an avalanche of display ads right now is no surprise.  It really is useful, too - not a gimmick.  Especially in the mobile space but also in the desktop.

The number of very useful content properties they've sewn together over the years (Mail, Maps, Finance, News to name just a few) are not only incredibly useful but also really well done and improving all the time.  

But all that doesn't matter because when it comes down to it I trust Google and I *really* don't trust Facebook.  Also, there's just nothing all that impressive about Facebook technologically - except maybe scale.  And Google does that at least as well.

I was making a block diagram for Noteriety during the regroup phase of development and I noticed how mondrian-ish it was turning out. 

From a wired article about Wolfram Alpha:

And you might understand Wolfram’s excitement about being able to know the tail number of a plane overhead when you get that answering that question isn’t easy.

For one, there are a lot of planes in the sky. And two, even if you know which planes are in the sky, radar data is delayed, so Wolfram Alpha has to project a plane’s course. And it’s got to take into account that people can’t actually see planes that are very high in the sky.

(Emphasis mine).  Wow.

...in their current form.  Because no one ever reads them thoroughly.  And I don't blame them.  How many times has someone gone to the trouble of creating a detailed list of feature requirements, distributed them, gotten the requirements approved, implemented the feature and gotten a look of shock and horror when the feature isn't what the higher ups wanted.  

Well, it's either that or the document is written so badly that the developer just has to make some guesses on how the feature should work without ever working with customers first-hand.  

Either way it's one of those processes that has been decided by someone somewhere to work well and no one has ever reconsidered.  Every problem (outside of pure incompetence)  in a company - can find its roots in miscommunication.  And the requirements document is the poster child for miscommunication.  Which is ironic since it was designed to avoid that very problem.

So why is this scourge such a problem?  It's boring.  I don't mean waiting room boring.  I mean the kind of boring where brains atrophy and desperate searches for utensils to impale oneself are commonplace.    No wonder no one wants to read these weapons of mass ambivalence.  But that's just the first and most important problem.  If there's someone who has the wherewithal to push through this forcefield of apathy they are met with what, in my experience, are a series of loosely related bullet points with little or no context.  

If I'm going to implement a feature I want to know when it's going to be used, why it's going to be used and most importantly how it's supposed to be used.  You could argue (in vain) that that's exactly what requirements documents do.  Not in my limited experience.  All I want to see in a requirements document is a series of use cases in paragraph form - starting with the user actions followed by the applications reaction to that action followed by the user's reaction and so on.  

Here's why.  First of all, I think that the writer of the requirements document is forced to think about these things a little more than just writing a bunch of bullet points.  That person has to understand the complete process and I guarantee he or she will realize many of the problems with some of the original thoughts laid down.  This saves back and forth time and quite possibly, if there is no back and forth, forcing the developer to come up with a solution without any input from someone who has experience with customers.  A solution that may ultimately be rejected very late in the process.

Second of all, it's much much easier to read something like that.  You're telling a story which gives the requirements context and make it more interesting.  The reader will not only get through it but will be able to have a complete understanding which, in turn, will hopefully start a dialog between the requirements writer, the developers and upper management.  

tl;dr : Make requirements documents just a series of concise use cases in paragraph form with, optionally, a very brief list of requirement bullet points at the beginning.  The requirements document should tell a story to engage the reader and make it more likely to get good feedback.

This is something that I've learned over the years of developing applications: know your place.  

When developing an application the authors need to understand how it will be used.  That's not news - in fact human interaction design is as old as app development (or almost as old).  But the part that I think is sometimes missed is the part that has to do with context.  If you're developing a note taking application, under no circumstances should that app take more than a second to launch.  Or, if it does take that long, it should not have to be launched more than once.  

It was when I had the idea for Stick that I realized that there are two classes of apps: primary and secondary.  Your primary apps are Word Processors, CAD application, Development IDEs and, for some, the web browser.  Secondary apps are todo lists, note takers, file browsers and the like.

This distinction is really important to understand before you start developing apps because it establishes requirements that affect pretty much all of its features.  For example, the aforementioned startup time.  It would suck to write a note taking application using bloated SDKs and GUI tools to give users the best possible experience only to realize that what they want is to get into the app fast and get out just as fast.  If your app takes a few seconds just to load the fancy UI then you've failed.  

I'm not saying nice UIs are not super important - they are.  But you can't go crazy with it if it's going to have an appreciable affect on the load time of your secondary app.  The reason load times on primary apps aren't as important is because they are often launched and left open all day- that's why I consider them primary apps.

Noteriety is an idea I had for a cross-platform non-centralized note keeper.  I know this is not a ground-breaking idea but it's a labor of love that was born of frustration with the note taking tools available.  As is so often the case, there are some tools that do some of the things I want and others that do a different set of things I like but none that have all the features I want.  Evernote is a perfect example of a tool that is ubiquitous, filled with features but the clients put a lot of focus in areas that I don't need leading to a bloated app that takes is not as accessible as it could be.

For me, note keepers are not research tools.  That is: I rarely have a need to clip some bit of info from a website and store it in a note.  Rather, I use note keepers to actually take notes from events that have occured.  Then reference those notes later.  Or I might be accumulate a cheat sheet of frequently used python commands that have lots of options that are hard to remember.  But either way I'm usually referring to a select few notes at any given time.  Having a view showing all my notes with hierarchical trees etc. is just not useful to me and polluted

To that end I created a purely command-line based notekeeper with some basic functions (e.g. add,edit,delete,get).  All command-line based.  After that, I expanded the command-line tool to run a web server that would serve up the same functionality in a web browser.  And that's where I am now.

Another big part of this is that I wanted something that was keyboard-focused.  So I borrowed some keyboard shortcuts from both vim and GMail.  So the keyboard shortcuts so far are:

It's a no frills note keeper but it's fast and easy to use and open-source.  There's no user login of any kind of course and all data is stored in a SQLite database.  The app is written in Python.  The web server is CherryPy and the database manipulation is done using SQLAlchemy's ORM.   Since this is Python, it works with any platform on which Python can be built. A requirement I set for myself before I started this thing.

I'm making this one open-source and will be updating it intermittently.  Go to bitbucket to browse the code and get the latest.

The usage string for the command-line app so far:

Noteriety - iWonder Designs 2011

usage: noteriety  [options]

Noteriety has two modes: web server and command-line client.  The default mode is command-line client.  To start
Noteriety as a web server simply use the "w" or "web" action as in:

    > noteriety web -p 80

All other actions are meant to be used as command-line interface (CLI) operations

Actions:

    web/w -- Start the web server
    add/a/+ -- Adds a note to the database
    delete/del/d/- -- Deletes a note from the database
    edit/ed/e/~ -- Modifies a note already in the database
    get/g -- Retrieves one or more notes from the database

Options:

    Both CLI and Web:

    -d, --db        Choose the database connection string to read from and write to.
                    Example: sqlite://
                    Applies to: CLI,Web

    -f, --file      Choose the sqlite database file to read from and write to. If the file does not
                        exist it will be created
                    Applies to: CLI,Web

    CLI Only:

    -n, --name      When creating or editing a note, this is the name of the note to use
                    Applies to: CLI
                    Default: 

    -b, --body      When creating or editing a note, this is the body of the note to use
                    Applies to: CLI
                    Required for actions: add

    -i, --id        When editing, retrieving or deleting notes this specifies which note is being referred to
                    Applies to: CLI
                    Required for actions: delete,edit

    -r,--renderer   Choose how outputted data should be displayed. Can be:
                        "simple" or "verbose"
                    Applies to: CLI
                    Default: verbose

    Web Only:
    
    -p, --port      The port number that the web server should listen on
                    Applies to: Web
                    Default: 8080

Examples:

    Add a note:
    > noteriety + -n "My First Note" -b "This is the text of my first note"

    Edit a note:
    > noteriety e -i 2 "My First Note - edited" -b "The body has been changed too"
    
    Delete a note:
    > noteriety - -i 1

    Get all notes:
    > noteriety g

    Get a single note:
    > noteriety g -i 1

    Start the web server on a specific port:
    > noteriety w -p 8081

Fox News is the second-most trusted network, but also the most distrusted one, with 42 percent trusting it and 46 percent not trusting it. That's as compared to the 43 percent who said they didn't trust CNN, CBS or ABC. But Fox News was one of only two networks that saw its distrust levels increase from last year's study. Last year, 37 percent of respondents said they didn't trust Fox--a nine-point difference from the 2011 poll.

5 minutes of reading through this article I learned something new:

The vertical distance between two block boxes is controlled by the margin-bottom property of the first box and the margin-top property of the second box (you’ve seen how to manipulate these earlier in the course). For boxes in the normal flow, ie boxes that aren’t floated or absolutely positioned, the vertical margins between two adjacent block boxes will collapse—overlap—so that the net result is not the sum of the two margins, but the greater of the two, as seen in Figure 1 below.

And, to think, I was sure I knew everything.

5 minutes of reading through this article I learned something new:

The vertical distance between two block boxes is controlled by the margin-bottom property of the first box and the margin-top property of the second box (you’ve seen how to manipulate these earlier in the course). For boxes in the normal flow, ie boxes that aren’t floated or absolutely positioned, the vertical margins between two adjacent block boxes will collapse—overlap—so that the net result is not the sum of the two margins, but the greater of the two, as seen in Figure 1 below.

And, to think, I was sure I knew everything.

From O'Reilly:

jQuery fires events of type “ajaxStart” and “ajaxStop” to indicate the start and stop of Ajax-related network activity. When jQuery is not performing any Ajax requests and a new request is initiated, it fires an “ajaxStart” event. If other requests begin before this first one ends, those new requests do not cause a new “ajaxStart” event. The “ajaxStop” event is triggered when the last pending Ajax request is completed and jQuery is no longer performing any network activity. This pair of events can be useful to show and hide a “Loading...” animation or network activity icon. For example:

$("#loading_animation").bind({
    ajaxStart: function() { $(this).show(); },
    ajaxStop: function() { $(this).hide(); }
});

These “ajaxStart” and “ajaxStop” event handlers can be bound to any document element: jQuery triggers them globally rather than on any one particular element.