E-mail is much more than a way for people to communicate. For freqent users of e-mail, it becomes their personal queue as well. The next generation of e-mail software needs to focus on making e-mail fulfill that role more smoothly.

One major challenge we often face is maintaining e-mail’s ease-of-use as our inbox gets filled with newsletters, notifications, sales reciepts, usenet posts, and chain e-mails from distant acquaintances.

Our inbox contains messages that vary in priority from nearly-spam notifications to critical conversations and high-priority to-do items. Notifications bury the important items quickly, and I find myself forwarding e-mails to myself so they stay on top a little while longer. It doesn’t have to be this hard! Most e-mail services and clients offer tagging features or flagging, but stop short of integrating those into a smooth workflow or allowing the inbox to be customized to take advantage of the data. To-do lists are great, but I never see them unless they appear in my inbox alongside my e-mails. Most to-do items originate from e-mails, so it makes sense that to-do items should really just be a tag or label for an e-mail. (E-mails sent to yourself should automatically get this tag).

50-70% of e-mails I receive come from a computer, not a human. I still need to see them, but only once, and I don’t need to reply. These crowd my inbox, and hide other much more important items. More on how these are easy to label later. 

Introducing the Thinbox

Some people like absolute control, others are lazy. I’m one of the lazy folk who want my computer to do all the work an keep things simple for me.  To handle this kind of person – I’m suggesting a whole new type of inbox – the thinbox…  This could live alongside the ‘inbox’ without any compatibility issues, I think. Gmail could implement this without a lot of trouble.

The thinbox is minimalistic. The goal is to only show items that need to be dealt with.  If I’m caught up, it’s empty – a blank screen. To achieve this feat, the user is ‘guided’ to deal with e-mails as they are read, and the view is limited to a certain time span (such as the last week or month). Archived items are never shown.

First, what types of e-mails do we get?

1. E-mails we want to see and handle now
   1. Reply, and the conversation disappears
   2. Read and act on. No reply needed; click Archive.
   3. Read and Archive. Completed conversations, or boring newsletters, sales reciepts, ship notifications, automatic notifications..
2. And ones I want to see later
   1. Skim and read later. Interesting newsletters, usenet posts, etc. Cool, but not right now.
   2. Read and remember to do something on a certain day. To-do item arrive in the form of an e-mail from a colleage or boss, an appointment reminder, or a bill.
   3. Read and reply later… when I have more data, or when I have more time, or when they get back from vacation/trip/etc

This brings us to a feature that we need to achieve our goal – we need to be able to have a e-mail re-appear at the top of an inbox on a given day. This could be implemented with a ‘reappearOn’ field. This allows us to ‘postpone’ an e-mail/todo.

Supporting features needed for thinbox

• Limiting by age in needed, because I will never sort my 9,079 old e-mails: Hide older than 1 day | week | month | all (probably needs to be group level)

• Results from following queries displayed one after another in the thinbox, with no divider (just a different background color, and a pop-out tab on the left that vertically spans all group items.
  • “Needs Reply”: Search inbox (not all mail) for e-mails I haven’t replied to, and aren’t flagged automatic, review, or to-do. Plus all e-mails tagged “Needs reply”. Defaults to 1 week visibility.
  • “Automatic”: Could be done with filters, but would be best done as a learning set of heuristics, based of user preferences. Users could black/whitelist addresses. Defaults to 1 day visibility.
  • “Up for review”: Articles tagged ‘review’, and have a review date before current time. This is a way to postpone/schedule e-mails and e-mails tagged ‘to-do’. A way to remind oneself about an e-mail at a certain time in the future – simply set a future date for it to reappear in the inbox (just sort by scheduled date instead of sent date when present). Defaults to 1 week visibility.
  • “to-do”: A simple default label. E-mails to oneself are automatically tagged. Defaults to 1 month visibility.
  • “Bored?”: (optional) A ‘quick’ label for e-mails that I don’t have time to read right now… Should probably stay minimized untill the other groups are empty.
• Quick links (on hover) for marking an item as “to-do”, “review”, “automatic”. Then choosing “soon, tomorrow, next week, next month” as the review time.
• It should be easy to manage groups as a whole: – a tab for each group in a left colum should allow batch archving, postponement, or re-labeling. 
• Automatic archiving when I reply (Send and Archive is default). Forwarded e-mails should suggest “Archive” and “Check Later”
• It is important to keep things clean… Instead of displaying the 5+ groups in separate boxes, put them inline, ordered by group, then date. Background color should differ by group. Groups disappear when they have no items.

Labeling ‘automatic’ e-mails.

Separating such ‘no reply’ e-mails from the rest isn’t very difficult – we can look for ‘unsubscribe’ links (newsletters) , large quantities of e-mail addresses in the TO field and the body (chain e-mails), keywords such as “order confirmation” or “reciept”, or addresses like no-reply/donotreply@domain.com.  I think we can flag these with 90% accuracy at least, and allow users to correct algorithm mistakes at the e-mail and e-mail adress levels.

Other gripes

Viewing all e-mails by a particular address should be a 1-click operation. If I’m looking at an e-mail from johndoe@company.com, there should be a “See all conversations with this person” link. It could appear when hovering over any e-mail address in the entire application – easy to implement. Preferably, other recent conversations should appear below the current conversation as links… Maybe the last 3?

How to implement several new high-profile .NET features in SmallTalk in less than a page of code.

Your Language Features Are My Libraries by Benjamin Pollack

I originally thought of lisp as being interpreted.. It’s easy to build a simple lisp interpreter.

Clojure, however, is compiled lisp – but still quite as dynamic, and it supports edit-and-continue.

Watch the video

Looks very promising

If so, don’t be too hard on yourself. It’s unfortunate, but the computer industry is more prone to group-think than any other. The inherent complexity requires us to take other people’s word for most things… Besides, it would seem that scripting languages are for scripts…right?

It’s true that scripting languages are fantastic at gluing libraries and applications together quickly. But they’re not just for scripts. Truthfully, any language can be used for ‘scripting’… But sophisticated high-level languages that excel at the job have an tendency to get branded. Ironic, eh?

Javascript, for instance

As a language, Javascript is one of the most high-level languages in existence. It was designed from the ground-up for object-oriented development (although with a quirky syntax). Its dynamic, reflective, and functional nature allows excellent code reuse (mix-ins, events, delegation, aspect integration), and the excellent array and dictionary syntax makes the language suitable for representing data and expressing domain-specific logic. It’s easy to unit test, and there are great IDEs for it (Aptana, Flex Builder).

Javascript is multi-paradigm. It is imperative, procedural, object-oriented, functional, and dynamic. If you want to write procedural garbage and use global variables, javascript will let you do it.

Javascript code you see on the Internet tends to be poorly written, buggy, and ugly. It’s not because the language is bad – it’s because few people learn how to use it properly. Developers copy and paste bad javascript, then write more code just like it. Thankfully, this trend is starting to reverse, and we’re seeing good javascript on a wide variety of sites. High-quality libraries like jQuery, Mootools, and YUI are showing developers what Javascript *should* look like, and how powerful it can be.

Javascript doesn’t get in your way, even if you’re doing something incredibly stupid. True, the syntax for making namespaces and classes could be improved, but the inherent flexibility lets you change even this – you can write defineNamespace(), defineClass(), and addMembers() functions if you so desire. Sometimes this freedom can get to your head, so remember that discipline is as important as ingenuity when writing code.

Javascript is a very high-level language, with excellent support for a variety of paradigms. It’s built into the JVM, every modern browser, and has over 20 server-side implementations.

The fact that it is possible to write javascript applications that run on a range of browers (implementations) is really amazing. Try writing an application that can run on Windows, Linux, and OS X without having targeted versions of the executable or the executing framework. Like everything else, javascript is easier in a consistent environment, like an AIR, Mozilla, or HTA app… Don’t blame the language for the framework. Don’t blame Javascript for the DOM.

On the desktop

The XML+Javascript combo is very suitable for large applications. Tying libraries together and defining the behavior of an application is definitely a job for a high-level dynamic language.

Here’s just a few desktop apps that use the Mozilla (XUL+Javascript) platform: Firefox, Flock, SeaMonkey, Thunderbird, Chatzilla, Nvu, Sunbird, ActiveState Komodo (my Python IDE), Joost, Miro, and Instantbird.

HTA (Microsoft HTML applications) have been around forever (2001?), and are used extensively within Microsoft products. I’ve written a few also, for windows-only tasks. They’re just HTML files with a .hta extension and local filesystem permissions. If only IE had debugging….

Adobe AIR is gaining immense popularity, and there are already thousands of apps out there. Need I say more? Javascript has proven itself a mature, capable language, suitable for big things.

Thank you, javascript

We have a lot to thank Javascript for. It’s a vector for single-paradigm developers to expand their horizons with. It’s pushing the performance boundaries of dynamic languages. Every six months a new virtual machine seems to be leapfrogging 50% over the previous leader. Smart just-in-time compilation is bringing incredible speeds to javascript, and with tiny initialization costs.

Python, for instance

Python is a little less implicit that Javascript, and follows the DRY principle very closely. It is designed to enforce readability, wheras Javascript relies on programmer discipline (which is needed anyway).

Python is used as a scripting language in lots of heavy-duty applications like GIMP, Inkscape, Blender, Maya, PSP, and… Linux. But it’s not named PythonScript, thank goodness, so the ‘scriptiness percepection index’ is much lower than javascript.

Lots of popular stuff is written in Python, like BitTorrent, Trac, Bazaar, Mercurial, TinyERP, ClamWin, Yum (linux package management system), Zope, and Django (my favorite). There are actually some drivers written in python. It’s pretty speedy.

Python is probably a good balance between power and guidance. It supports a variety of paradigms, but has great default behavior and tends to guide you towards doing things one way. Python is reflective, object-oriented, dynamic, and functional much like javascript. It’s a little stricter, but not enough to really annoy.

Ruby, Lisp, and Perl

I’m lumping these three together since I don’t have much experience with them. I’ve been studying them, though, and all three seem very powerful and sufficient in their own way. All three are incredibly popular, with hundreds of thousands of apps in the wild.

My defintion of high-level

At one time C was considered a high-level language. At one time C++ was considered a high-level language. Not too long ago I considered Java a high-level language.

In my opinion, a true high-level language must allow programming with the following paradigms as a minimum

• dynamic (Any member can be overridden, objects act like dictionaries)
• reflective (Members are enumerable, executable, and can be referenced by string name)
• functional (Functions are first-class objects, with members)
• object-oriented (Functionality can be organized into objects, which can have instances containing state)
• Imperative

It must also have these features

• In-line documentation
• Built-in list and dictionary syntax.
• Variadic functions
• Easy ‘undefined’ and null checks
• Exception management
• Duck typing (optional explicit typing is OK)
• Automatic memory management
• Closures, anonymous functions
• Good list, dictionary, string, math, and date libraries.

I don’t believe the future is in contract-based programming. The contract safety that interfaces and classes provide is shallow and of questionable value. It is behavior, not integration that typically causes problems.

A far better approach is to use a language that facilitates defensive programming and easy unit testing.

It’s easy. Put return this; before the end of each method in your class. Just say no to void!

Of course, you wouldn’t do it on functions. They’re supposed to return data. But following this practice for ‘command’ methods makes perfect sense, and allows calling code to be much cleaner.

Compare:

Element para = new Element("p");
para.set("class","song");
para.append("Hello World");
para.appendTo(document);

to

new Element("p") .set("class","song") .append("Hello World") .appendTo(document);

or

new Element("p") .set("class","song")
                 .append("Hello World")
                 .appendTo(document);

#2 and #3 are far more readable. If you want to draw attention to the commands (say they aren’t transparently obvious, or need inline comments), #3 is a better choice. If you want to focus on the surrounding logic, #2 cuts line usage down tremendously.

Both remove repetition and reduce re-factoring costs. As a bonus, you don’t have to clutter the scope with another arbitrarily named variable; you’ve created and finished with the object all in one statement.

Like all coding practices, there is a short adjustment period while you get used to reading and writing this style; however, I’m confident you’ll find it much faster to read and write code without that superfluous, repetitive text. DRY.

Just say no to void. Be nice to your callers.

<(?<tagname>[\\w:-]+)(?<attrpair>\\s+(?<attrname>\\w[-\\w:]*)
(\\s*=\\s*\"(?<attrval>[^\"]*)\"|
\\s*=\\s*'(?<attrval>[^']*)'|
\\s*=\\s*(?<attrval><%#.*?%>)|
\\s*=\\s*(?<attrval>[^\\s=/>]*)|
(?<attrval>\\s*?)))*
\\s*(?<insertattrs>)(?:(?<empty>/>)|>
(?s:(?<contents>.*?)
(?i:</\\s*\\k<tagname>\\s*>)))

Whenever I did string parsing, I usually ended up with masses of loops and indexOf calls. I tried to avoid anything complicated, but the parsing code inevitably ended up huge, fragile, and difficult to read.

During those six years, I probably wrote over ten thousand lines of string parsing code that could have been replaced with ten or twenty lines of regular expressions. Really.

If you do any kind of programming, or even just work with text, you need to understand regular expressions. They’re very, very useful. So useful, in fact, that it’s near impossible to find a language that doesn’t support them. Perl, PHP, Ruby and Javascript even add syntactic sugar to make them easier to use.

Regex patterns

Regex patterns don’t have to be complicated to be useful. You’ll probably get the most mileage out of simple patterns – quick regexes that save you a few dozen lines of code.

For example, you might scan text for simple e-mail addresses with this pattern:

[a-z]+@[a-z]+\.[a-z]

Within square brackets, you can list allowed characters like this: [abcdefghijklm] or specify a range: [a-m].

The + symbol means ‘one or more’ of whatever it is following. So “A+” would match A or AAA or AAAAA. (*) means ’0 or more’.

The period (.) means ‘any character’. Since we’re actually trying to match a period, we have to ‘escape’ it with a backslash: \.

Unfortunately, the above regex dosen’t match e-mail addresses like joe@example.co.uk. It also won’t match joe@example-domain.com or first-last@me9.com. Here’s an improved version.

[a-z0-9._-]+@[a-z0-9.-]+\.[a-z]

And here’s an even more sophisticated version. It excludes domains that start or end in an hyphen. It also prevents more than one period in a row in the domain or username.

[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*

@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?

Experiment

http://rubular.com/

Continued

http://en.wikipedia.org/wiki/Regular_expression

http://www.regular-expressions.info/