Ian Bicking: a blog - mozilla

“Users want control” is a shoulder shrug

2019-04-23T00:00:00-05:00

Making the claim “users want control” is the same as saying you don’t know what users want, you don’t know what is good, and you don’t know what their goals are.

I first started thinking about this during the debate over what would become the ACA. The rhetoric was filled with this idea that people want choice in their medical care: people want control.

No! People want good health care. If they don’t trust systems to provide them good health care, if they don’t trust their providers to understand their priorities, then choice is the fallback: it’s how you work the system when the system isn’t working for you. And it sucks! Here you are, in the middle of some health issue, with treatments and symptoms and the rest of your life duties, and now you have to become a researcher on top of it? But the politicians and the pundits could not stop talking about control.

Control is what you need when you want something and it won’t happen on its own. But (usually) it’s not control you want, it’s just a means.

So when we say users want control over X – their privacy, their security, their data, their history – we are first acknowledging that current systems act against users, but we aren’t proposing any real solution. We’re avoiding even talking about the problems.

For instance, we say “users want control over their privacy,” but what people really want is some subset of:

To avoid embarrassment
To avoid persecution
… sometimes for doing illegal and wrong things
To keep from having the creeping sensation they left something sitting out that they didn’t want to
They want to make some political statement against surveillance
They want to keep things from the prying eyes of those close to them
They want to avoid being manipulated by bad-faith messaging

There’s no easy answers, not everyone holds all these desires, but these are concrete ways of thinking about what people want. They don’t all point in the same direction. (And then consider the complex implications of someone else talking about you!)

There are some cases when a person really does want control. If the person wants to determine their own path, if having choice is itself a personal goal, then you need control. That’s a goal about who you are not just what you get. It’s worth identifying moments when this is important. But if a person does not pay attention to something then that person probably does not identify with the topic and is not seeking control over it. “Privacy advocates” pay attention to privacy, and attain a sense of identity from the very act of being mindful of their own privacy. Everyone else does not.

Let’s think about another example: users want control over their data. What are some things they want?

They don’t want to lose their data
They don’t want their data used to hold them hostage (e.g., to a subscription service)
They don’t want to delete data and have it still reappear
They want to use their data however they want, but more likely they want their data available for use by some other service or tool
They feel it’s unfair if their data is used for commercial purposes without any compensation
They are offended if their data is used to manipulate themselves or others
They don’t want their data used against them in manipulative ways
They want to have shared ownership of data with other people
They want to prevent unauthorized or malicious access to their data

Again these motivations are often against each other. A person wants to be able to copy their data between services, but also delete their data permanently and completely. People don’t want to lose their data, but having personal control over your data is a great way to lose it, or even to lose control over it. The professionalization and centralization of data management by services has mostly improved access control and reliability.

When we simply say users want control it’s giving up on understanding people’s specific desires. Still it’s not exactly wrong: it’s reasonable to assume people will use control to achieve their desires. But if, as technologists, we can’t map functionality to desire, it’s a bit of a stretch to imagine everyone else will figure it out on the fly.

Open Source Doesn’t Make Money Because It Isn’t Designed To Make Money

2019-03-18T00:00:00-05:00

Or: The Best Way To Do Something Is To At Least Try

We all know the story: you can’t make money on open source. Is it really true?

I’m thinking about this now because Mozilla would like to diversify its revenue in the next few years, and one constraint we have is that everything we do is open source.

There are dozens (hundreds?) of successful open source projects that have tried to become even just modest commercial enterprises, some very seriously. Results aren’t great.

I myself am trying to pitch a commercial endeavor in Mozilla right now (if writing up plans and sending them into the ether can qualify as “pitching”), and this question often comes up in feedback: can we sell something that is open source?

I have no evidence that we can (or can’t), but I will make this assertion: it’s hard to sell something that wasn’t designed to be sold.

We treat open source like it’s a poison pill for a commercial product. And yes, with an open source license it’s harder to force someone to pay for a product, though many successful businesses exist without forcing anyone.

I see an implicit assumption that makes it harder to think about this: the idea that if something is useful, it should be profitable. It’s an unspoken and morally-infused expectation, a kind of Just World hypothesis: if something has utility, if it helps people, if it’s something the world needs, if it empowers other people, then there should be a revenue opportunity. It should be possible for the thing to be your day job, to make money, to see some remuneration for your successful effort in creating or doing this thing.

That’s what we think the world should be like, but we all know it isn’t. You can’t make a living making music. Or art. You can’t even make a living taking care of children. I think this underlies many of this moment’s critiques of capitalism: there’s too many things that are important, even needed, or that fulfill us more than any profitable item, and yet are economically unsustainable.

I won’t try to fix that in this blog post, only note: not all good things make money.

But we know there is money in software. Lots of money! Is the money in secrets? If OpenSSL was secret, could it make money? If it had a licensing paywall, could it make money? Seems unlikely. The license isn’t holding it back. It’s just not shaped like something that makes money. Solving important problems isn’t enough.

So what can you get paid to do?

People will pay a little for apps; not a lot, but a bit. Scaling up requires marketing and capital, which open source projects almost never have (and I doubt many open source projects would know what to do with capital if they had it).
There’s always money in ads. Sadly. This could potentially offend someone enough to actually repackage your open source software with ads removed. As a form of price discrimination (e.g., paid ad removal) I think you could avoid defection.
Fully-hosted services: Automattic’s wordpress.com is a good example here. Is Ghost doing OK? These are complete solutions: you don’t just get software, you get a website.
People will pay if you ensure they get a personalized solution. I.e., consulting. Applied to software you get consultingware. While often maligned, many real businesses are built on this. I think Drupal is in this category.
People will pay you for your dedicated and ongoing attention. In other words: a day job as an employee. It feels unfair to put this option on the list, but it’s such a natural progression from consultingware, and such a dominant pattern in open source that I think it deserves acknowledgement.
Anything paired with a physical device. People will judge the value based on the hardware and software experience together.
I’m not sure if Firefox makes money (indirectly) from ads, or as compensation for maintaining monopoly positions.

I’m sure I’m missing some interesting ideas from that list.

But if you have a business concept, and you think it might work, what does open source even have to do with it? Don’t we learn: focus on your business! On your customer! Software licensing seems like a distraction, even software is a questionable thing to focus on, separate from the business. Maybe this is why you can’t make money with open source: it’s a distraction. The question isn’t open-source-vs-proprietary, but open-source-vs-business-focused.

Another lens might be: who are you selling to? Classical scratch-your-own-itch open source software is built by programmers for programmers. And it is wildly successful, but it’s selling to people who aren’t willing to pay. They want to take the software and turn it around into greater personal productivity (which turns out to be a smart move, given the rise in programmer wages). Can we sell open source to other people? Can anyone else do anything with source code?

And so I remain pessimistic that open source can find commercial success. But also frustrated: so much software is open source except any commercial product. This is where the Free Software mission has faltered despite so many successes: software that people actually touch isn’t free or open. That’s a shame.

You may also wish to read Hacker News Comments on this post, or the Reddit r/programming comments

The Firefox Experiments I Would Have Liked To Try

2019-03-04T00:00:00-06:00

I have been part of the Firefox Test Pilot team for several years. I had a long list of things I wanted to build. Some I didn’t personally want to build, but I thought they were interesting ideas. I didn’t get very far through this list at all, and now that Test Pilot is being retired I am unlikely to get to them in the future.

Given this I feel I have to move this work out of my head, and publishing a list of ideas seems like an okay way to do that. Many of these ideas were inspired by something I saw in the wild, sometimes a complete product (envy on my part!), or the seed of an idea embedded in some other product.

The experiments are a spread: some are little features that seem potentially useful. Others are features seen elsewhere that show promise from user research, but we could only ship them with confidence if we did our own analysis. Some of these are just ideas for how to explore an area more deeply, without a clear product in mind.

Test Pilot’s purpose was to find things worth shipping in the browser, which means some of these experiments aren’t novel, but there is an underlying question: would people actually use it? We can look at competitors to get ideas, but we have to ship something ourselves if we want to analyze the benefit.

Table of contents:

Sticky Reader Mode
Cloud Browser
Modal Page Actions
Find+1
Your Front Page
Page Archive
Personal Historical Archive
Navigational Breadcrumbs
Copy Keeper
Change Scout
Popup Tab Switcher
Personal Podcast
Bookmark Manager
Extended Library
Text Mobile Screenshot
Email Readable
Your History Everywhere
My Homepage
Studying what Electron does for people
App quick switcher
Just Save
Open Search Combined Search
Notes Commander
Automater
Sidekick
Timed Repetition
Reader Mode improvements
Digest Mode
Firefox for X
- Firefox Study
- Firefox Media
- Firefox for Finance
- Firefox Low Bandwidth
- Firefox for Kids
- Firefox Calm
Concluding thoughts

Sticky Reader Mode

Give Reader Mode in Firefox a preference to make it per-domain sticky. E.g. if I use Reader Mode on nytimes.com and then if I visit an article on nytimes.com in the future it’ll automatically convert to reader mode. (The nytimes.com homepage would not be a candidate for that mode.)

I made an experiment in sticky-reader-mode, and I think it works really nicely. It changes the browsing experience significantly, and most importantly it doesn’t require frequent proactive engagement to change behavior. Lots of these proposed ideas are tools that require high engagement by the user, and if you don’t invoke the tool then they do nothing. In practice no one (myself included) remembers to invoke these tools. Once you click the preference on a site Sticky Reader Mode then you are opted in to this new experience with no further action required.

There are a bunch of similar add-ons. Sticky Reader Mode works a bit better than most because of its interface, and it will push you directly into Reader Mode without rendering the normal page. But it does this by using APIs that are not public to normal WebExtensions. As a result it can’t be shipped outside Test Pilot, and can’t go in addons.mozilla.org. So… just trust me, it’s great.

Recently I’ve come upon Brave Speed Reader which is similar, but without per-site opt-in, and using machine learning to identify articles.

Cloud Browser

Run a browser/user-agent in the cloud and use a mobile view as a kind of semantic or parsed view on that user agent (the phone would just control the browser that is hosted on the cloud). At its simplest we just take the page, simplify it in a few ways, and send it on - similar to what Opera Mini does. The approach lends itself to a variety of task-oriented representations of remote content.

When I first wrote this down I had just stared at my phone while it took 30 seconds to show me a 404 page. The browser probably knew after a couple seconds that it was a 404 but it acted as a rendering engine and not a user agent, so the browser insisted on faithfully rendering the useless not found page.

Obviously running a full browser instance in the cloud is resource hungry and finicky but I think we could ignore those issues while testing. Those are hard but solved operational issues.

Prior art: Opera Mini does some of this. Puffin is specifically cloud rendering for mobile. Light Point does the same for security reasons.

I later encountered brow.sh which is another interesting take on this (specifically with html.brow.sh).

This is a very big task, but I still believe there’s tremendous potential in it. Most of my concepts are not mobile-based, in part because I don’t like mobile, I don’t like myself when using a mobile device, and it’s not something I want to put my energy into. But I still like this idea.

Modal Page Actions

This was tangentially inspired by Vivaldi’s Image Properties, not because of the interface, but thinking about how to fit high-information inspection tools into the browser.

The idea: instead of context menus, page actions, or other interaction points that are part of the “chrome”, implement one overlay interface: the do-something-with-this-page interface. Might also be do-something-with-this-element (e.g. replacing the 7 image-related context menu items: View Image, Copy Image, Copy Image Location, Save Image As, Email Image, Set As Desktop Background, and View Image Info).

The interface would be an overlay onto the page, similar to what happens when you start Screenshots:

Everything that is now in the Page Action menu (the ... in the URL bar), or in the context menu, would be available here. Some items might have a richer interface, e.g., Send Tab To Device would show the devices directly instead of using a submenu. Bookmarking would include some inline UI for managing the resulting bookmark, and so on.

There was some pushback because of the line of death – that is, the idea all trusted content must clearly originate from the browser chrome, and not the content area. I do not believe in the Line of Death, it’s something users could use to form trust, but I don’t believe they do use it (further user research required).

The general pattern is inspired by mobile interfaces which are typically much more modal than desktop interfaces. Modal interfaces have gotten a bad rap, I think somewhat undeserved: modal interfaces are also interfaces that guide you through processes, or ask you to explicitly dismiss the interface. It’s not unreasonable to expect someone to finish what they start.

Find+1

We have find-in-page but what about find-in-anything-linked-from-this-page?

Hit Cmd-Shift-F and you get an interface to do that. All the linked pages will be loaded in the background and as you search we show snippets of matching pages. Clicking on a snippet opens or focuses the tab and goes to where the search term was found.

I started experimenting in find-plus-one and encountered some challenges: hidden tabs aren’t good workers, loading pages in the background takes a lot of grinding in Firefox, and most links on pages are stupid (e.g., I don’t want to search your Careers page). An important building block would be a way to identify the important (non-navigational) parts of a page. Maybe lighter-weight ways to load pages (in other projects I’ve used CSP injection). The Copy Keeper concept did come about while I experimented with this.

A simpler implementation of this might simply do a text search of all your open tabs, which would be technically simpler and mostly an exercise in making a good representation of the results.

Your Front Page

Create a front page of news from the sites you already visit. Like an RSS reader, but prepopulated with your history. This creates an immediate well-populated experience.

My initial thought was to use ad hoc parsers for popular news sites, and at run an experiment with just a long whitelist of news providers.

I got the feedback: why not just use RSS? Good question: I thought RSS was kind of passé, but I hadn’t looked for myself. I went on to do some analysis of RSS, and found it available for almost all news sites. The autodetection (<link rel=alternate>) is not as widely available, and it requires manual searching to find many feeds. Still RSS is a good way to get an up-to-date list of articles and their titles. Article content isn’t well represented and other article metadata is inaccurate or malformed (e.g., there are no useful tags). So using RSS would be very reasonable discovery mechanism, but an “RSS reader” doesn’t seem like a good direction on the current web.

Page Archive

This is bringing back old functionality from Page Shot, a project of mine which morphed into Firefox Screenshots: save full DOM copies of pages. What used to be fairly novel is now well represented by several projects (e.g., WebMemex or World Brain Memex).

Unfortunately I have never been able to really make this kind of tool part of my own day-to-day behavior, and I’ve become skeptical it can work for a general populace. But maybe there’s a way to package up this functionality that is more accessible, or happens more implicitly. I forked a version of Page Shot as pagearchive a while ago, with this in mind, but I haven’t (and likely won’t) come back to it.

Personal Historical Archive

This isn’t really a product idea, but instead an approach to developing products.

One can imagine many tools that directly interact or learn from the content of your browsing. There is both a privacy issue here and a privacy opportunity: looking at this data is creepy, but if the tools live in your user agent (that belongs to you and hosts your information locally) then it’s not so creepy.

But it’s really hard to make experiments on this because you need a bunch of data. If you build a tool that starts watching your browsing then it will only slowly build up interesting information. The actual information that is already saved in browser history is interesting, but in my experience it is too limited and of poor quality. For instance, it is quite hard to build up a navigational path from the history when you use multiple tabs.

A better iterative development approach would be one where you have a static set of all the information you might want, and you can apply tools to that information. If you find something good then later you can add new data collection to the browser, secure in the knowledge that it’s going to find interesting things.

I spent quite a bit of effort on this, and produced `personal-history-archive. It’s something I still want to come back to. It’s a bit of a mess, because at various times it was retrofitted to collect historical information, or collect it on an ongoing basis, or collected it when driven by a script. I also tried to build tools in parallel for doing analysis on the resulting database.

This is also a byproduct of experimentation with machine learning. I wanted to apply things I was learning to browser data, but the data I wanted wasn’t there. I spent all my time collecting and cleaning data, and ended up spending only a small amount of time analyzing the data. I suspect I’m not the only one who has done this.

Navigational Breadcrumbs

When I click on a link I lose the reminder of why I clicked on it. What on the previous page led me to click on this? Was I promised something? Are there sibling links that I might want to continue to directly instead of going back and selecting another link?

This tool would give you additional information about the page you are on, how you got there, and given where you came from, where you might go next. Would this be a sidebar? Overlay content? In a popup? I’m not sure.

Example: using this, if I click on a link from Reddit I will be able to see the title of the Reddit post (which usually doesn’t match the document title), and a link to comments on the page. If I follow a link from Twitter, I’ll be able to see the Tweet I came from.

This could be interesting paired with link preview (like a tentative forward). Maybe the mobile browser Linkbubbles (now integrated into Brave) has some ideas to offer.

Technically this will use some of the techniques from Personal History Archive, which tracks link sources.

This is based on the train of thought I wrote down in an HN comment – itself a response to Freeing the Web from the Browser.

I want to try this still, and have started a repo crossnav but haven’t put anything there yet. I think even some naive approaches could work, just trying to detect the category of link and the related links (e.g., on Reddit the category is other submissions, and the related links are things like comments).

Copy Keeper

A notebook/logbook that is filled in every time you copy from a web page. When you copy it records (locally):

Text of selection
HTML of selection
Screenshot of the block element around the selection
Text around selection
Page URL and nearest anchor/id
Page title
Datetime

This overloads “copy” to mean “remember”.

Clips would be searchable, and could be moved back to the clipboard in different forms (text, HTML, image, bibliographical reference, source URL). Maybe clips would be browsable in a sidebar (maybe the sidebar has to be open for copies to be collected), or clips could be browsed in a normal tab (Library-style).

I created a prototype in copy-keeper. I thought it was interesting and usable, though whether it would actually get any use in practice I don’t know. It’s one of those tools that seems handy but requires effort, and as a result doesn’t get used.

Change Scout

(Wherein I both steal a name from another team, and turn it into a category…)

Change Scout will monitor a page for you, and notify you when it changes. Did someone edit the document? Was there activity on an issue? Did an article get updated? Put Change Scout to track it and it will tell you what changes and when.

It would monitor the page inside the browser, so it would have access to personalized and authenticated content. A key task would be finding ways to present changes in an interesting and compact way. In another experiment I tried some very simple change detection tools, and mostly end up frustrated (small changes look very large to naive algorithms).

Popup Tab Switcher

We take the exact UI of the Side View popup, but make it a tab switcher. “Recent Tabs” are the most recently focused tabs (weighted somewhat by how long you were on the tab), and then there’s the complete scrollable list. Clicking on an item simply focuses that tab. You can close tabs without focusing them.

I made a prototype in tab-switchr. In it I also added some controls to close tabs, which was very useful for my periodic tab cleanups. Given that it was a proactive tool, I surprised myself by using it frequently. There’s work in Firefox to improve this, unrelated to anything I’ve done. It reminds me a bit of various Tree-Style Tabs, which I both like because they make it easier to see my tabs, and dislike because I ultimately am settled on normal top-tabs. The popup interface is less radical but still provides many of the benefits.

I should probably clean this up a little and publish it.

Personal Podcast

Create your own RSS feed.

When you are on a page with some audio source, you can add the audio to your personal feed
When on an article, you can generate an audio version that will be added to the feed
You get an RSS feed with a random token to make it private (I don’t think podcast apps handle authentication well, but this requires research)
Maybe you can just send/text the link to add it to your preferred podcast app
If apps don’t accept RSS links very well, maybe something more complicated would be required. An app that just installs an RSS feed? We want to avoid the feed accidentally ending up in podcast directories.

Bookmark Manager

There’s a lot of low-rated bookmark managers in addons.mozilla.org and the Chrome Extension store. Let’s make our own low-rated bookmark manager!

But seriously, this would anticipate updates to the Library and built-in bookmark manager, which are deficient.

Some resources/ideas: * Comment with a few gripes * Google’s bookmark manager * Bookmark section on addons.mozilla.org * Bookmark organizers on addons.mozilla.org * Relevant WebExtension APIs

Extended Library

The “Library” in Firefox is the combination history and bookmark browser you get if you use “Show all bookmarks” or “Show all history”.

In this idea we present the user with a record of their assets, wherever they are.

This is like a history view (and would be built from history), but would use heuristics to pick out certain kinds of things: docs you’ve edited, screenshots you’ve taken, tickets you’ve opened, etc. We’d be trying hard to find long-lived documents in your history, instead of transitional navigation, articles, things you’ve gotten to from public indexes, etc.

Automatically determining what should be tagged as a “library item” would be the hard part. But I think having an organic view of these items, regardless of underlying service, would be quite valuable. The browser has access to all your services, and it’s easy to forget what service hosts the thing you are thinking about.

Text Mobile Screenshot

This tool will render the tab in a mobile factor (using the devtools responsive design mode), take a full-page screenshot, and text the image and URL to a given number. Probably it would only support texting to yourself.

I’ve looked into this some, and getting the mobile view of a page is not entirely obvious and requires digging around deep in the browser. Devtools does some complicated stuff to display the mobile view. The rest is basic UI flows and operational support.

Email Readable

Emails the Reader Mode version of a site to yourself. In our research, people love to store things in Email, so why not?

Though it lacks the simplicity of this concept, Email Tabs contains this basic functionality. Email This does almost exactly this.

Your History Everywhere

An extension that finds and syncs your history between browsers (particularly between Chrome and Firefox).

This would use the history WebExtension APIs. Maybe we could create a Firefox Sync client in Chrome. Maybe it could be a general way to move things between browsers. Actual synchronization is hard, but creating read-only views into the data in another browser profile is much easier.

Obviously there’s lots of work to synchronize this data between Firefox properties, and knowing the work involved this isn’t easy and often involves close work with the underlying platform. Without full access to the platform (like on Chrome) we’ll have to find ways to simplify the problem in order to make it feasible.

My Homepage

Everyone (with an FxA account) gets there own homepage on the web. It’s like Geocities! Or maybe closer to github.io.

But more seriously, it would be programmatically accessible simple static hosting. Not just for you to write your own homepage, but an open way for applications to publish user content, without those applications themselves turning into hosting platforms. We’d absorb all the annoyances of hosting content (abuse, copyright, quotas, ops, financing) and let open source developers focus on enabling interesting content generation experiences for users on the open web.

Here’s a general argument why I think this would be a useful thing for us to do. And another from Les Orchard.

Studying what Electron does for people

This is a proposal for user research:

Electron apps are being shipped for many services, including services that don’t require any special system integration. E.g., Slack doesn’t require anything that a web browser can’t do. Spotify maybe catches some play/pause keys, but is very close to being a web site. Yet there is perceived value in having an app.

The user research would focus on cases where the Electron app doesn’t have any/many special permissions. What gives the app value over the web page?

The goal would be to understand the motivations and constraints of users, so we could consider ways to make the in-browser experience equally pleasant to the Electron app.

App quick switcher

Per my previous item: why do I have an IRCCloud app? Why do people use Slack apps? Maybe it’s just because they want to be able to switch into and out of those apps quickly.

A proposed product solution: add a shortcut to any specific (pinned?) tab. Might be autocreated. Using the shortcut when the app is already selected will switch you back to your previous-selected tab. Switching to the tab without the shortcut will display a gentle reminder that the shortcut exists (so you can train yourself to start using it).

To make it a little more fancy, I thought we might also be able to do a second related “preview” shortcut. This would let you peek into the window. I’m not sure what “peeking” means. Maybe we just show a popup with a screenshot of that other window.

Maybe this should all just overload ⌘1/2/3 (maybe shift-⌘1/etc for peeking). Note these shortcuts do not currently have memory – you can switch to the first tab with ⌘1, but you can’t switch back.

This is one suggested solution to Whatever Electron does for people.

I started some work in quick-switch-extension, but keyboard shortcuts were a bit wonky, and I couldn’t figure out useful additional functionality that would make it fun. Firefox (Nightly?) now has Ctrl-Tab functionality that takes you to recent tabs, mitigating this problem (though it is not nearly as predictable as what I propose here).

Just Save

Just Save saves a page. It’s like a bookmark. Or a remembering. Or an archive. Or all of those all at once.

Just Save is a one-click operation, though a popup does show up (similar in function to Pocket) that would allow some additional annotation of your saved page.

We save: 1. Link 2. Title 3. Standard metadata 4. Screenshot 5. Frozen version of page 6. Scroll position 7. The tab history 8. Remember the other open tabs, so if some of them are saved we offer later relations between them 9. Time the page was saved 10. Query terms that led to the page

It’s like bookmarks, but purely focused on saving, while bookmarks do double-duty as a navigational tool. The tool encourages after-the-fact discovery and organization, not at-the-time-of-save choices.

And of course there’s a way to find and manage your saved pages. This idea needs more exploration of why you would return to a page or piece of information, and thus what we’d want to expose and surface from your history. We’ve done research, but it’s really just a start.

Open Search Combined Search

We have several open search providers. How many exist out there? How many could we find in history?

In theory Open Search is an API where a user could do personalized search across many properties, though I’m not sure if any sufficient number of sites has enabled it.

Notes Commander

It’s Notes, but with slash commands.

I other words it’s a document, but if you complete a line that begins with a / then it will try to execute that command, appending or overwriting from that point.

So for instance /timestamp just replaces itself with a timestamp.

Maybe /page inserts the currently active tab. /search foo puts search results into the document, but as editable (and followable) links. /page save freezes the page as one big data link, and inserts that link into the note.

It’s a little like Slack, but in document form, and with the browser as the context instead of a messaging platform. It’s a little like a notebook programming interface, but less structured and more document-like.

The ability to edit the output of commands is particularly interesting to me, and represents the kind of ad hoc information organizing that we all do regularly.

I experimented some with this in Notes, and got it working a little bit, but working with CKEditor (that Notes is built on) was just awful and I couldn’t get anything to work well. Notes also has a very limited set of supported content (no images or links), which was problematic. Maybe it’s worth doing it from scratch (with ProseMirror or Slate?)

After I tried to mock this up, I realized that the underlying model is much too unclear in my mind. What’s this for? When is it for? What would a list of commands look like?

Another thing I realized while attempting a mockup is that there should be a rich but normalized way to represent pages and URLs and so forth. Often you’ll be referring to URLs of pages that are already open. You may want to open sets of pages, or see immediately which URLs are already open in a tab. A frozen version of a page should be clearly linked to the source of that page, which of course could be an open tab. There’s a lot of pieces to fit together here, both common nouns and verbs, all of which interact with the browser session itself.

Automater

Automation and scripting for your browser: make demonstrations for your browser, give it a name, and you have a repeatable script.

The scripts will happen in the browser itself, not via any backend or scraping tool. In case of failed expectations or changed sites, the script will halt and tell the user.

Scripts could be as simple as “open a new tab pointing to this page every weekday at 9am”, or could involve clipping information, or just doing a navigational pattern before presenting the page to a user.

There’s a huge amount of previous work in this area. I think the challenge here is to create something that doesn’t look like a programming language displayed in a table.

Sidekick

Sidekick is a sidebar interface to anything, or everything, contextually. Some things it might display:

Show you the state of your clipboard
Show you how you got to the current tab (similar to Navigational Breadcrumbs)
Show you other items from the search query that kicked off the current tab
Give quick navigation to nearby pages, given the referring page (e.g., the next link, or next set of links)
Show you buttons to activate other tabs you are likely to switch to from the current tab
Show shopping recommendations or other content-aware widgets
Let you save little tidbits (text, links, etc), like an extended clipboard or notepad
Show notifications you’ve recently received
Peek into other tabs, or load them inline somewhat like Side View
Checklists and todos
Copy a bunch of links into the sidebar, then treat them like a todo/queue

Possibly it could be treated like an extensible widget holder.

From another perspective: this is like a continuous contextual feature recommender. I.e., it would try to answer the question: what’s the feature you could use right now?

Timed Repetition

Generally in order to commit something to long-term memory you must revisit information later, ideally long enough that it’s a struggle.

Is anything we see in a browser worth committing to long-term memory? Sometimes it feels like nothing is worth remembering, but that’s a kind of nihilism based on the shitty aspects of typical web browsing behavior.

The interface would require some positive assertion: I want to know this. Probably you’d want to highlight the thing you’d “know”. Then, later, we’d want to come up with some challenge. We don’t need a “real” test that is verified by the browser, instead we simply need to ask some related question, then the user can say if they got it right or not (or remembered it or not).

More information on the general technique in the Spaced Repetition Wikipedia article.
Incremental Reading is an approach to information consumption paired with flashcard review.
Anki is the most prominent open source software in this area. Oddly while there is a lot of WebExtension-based intake software for it, the actual testing is primarily done in a native app.
A bizarre hard-to-read font meant to aid in memory.

Reader Mode improvements

Reader mode is a bit spartan. Maybe it could be a bit nicer:

Pick up some styles or backgrounds from the hosting site
Display images or other media differently or more prominently
Add back some markup or layout that Readability erases
Apply to some other kinds of sites that aren’t articles (e.g., a video site)
A multicolumn version like McReadability

Digest Mode

Inspired by Full Hacker News (comments): take a bunch of links (typically articles) and concatenate their content into one page.

Implicitly this requires Reader Mode parsing of the pages, though that is relatively cheap for “normal” articles. Acquiring a list of pages is somewhat less clear. Getting a list of pages is a kind of news/RSS question. Taking a page like Hacker News and figuring out what the “real” links are is another approach that may be interesting. Lists of related links are everywhere, yet hard to formally define.

This would work very nicely with complementary text summarization.

Open question: is this actually an interesting or useful way to consume information?

Firefox for X

There’s an underlying concept here worth explaining:

Feature develop receives a lot of skepticism. And it’s reasonable: there’s a lot of conceit in a feature, especially embedded in a large product. Are people going to use a product or not because of some little feature? Or maybe the larger challenge: can some feature actually change behavior? Every person has their own thing going on, people aren’t interested in our theories, and really not that many people are interested in browsers. Familiar functionality – the back button, bookmarks, the URL bar, etc. – are what they expect, what they came for, and what they will gravitate to. Everything I’ve written so far in this list are things people won’t actually use.

A browser is particularly problematic because it’s so universal. It’s for sites and apps and articles. It’s for the young and the elderly, the experienced and not. It’s used for serious things, it’s used for concentration, and it’s used for dumb things and to avoid concentrating. How can you build a feature for everyone, targeting anything they might do? And if you build something, how can a person trust a new feature is really for them, not some other person? People are right to be skeptical of the new!

But we also know that most people regularly use more than one browser. Some people use Chrome for personal stuff, and Firefox for work. Some people do the exact opposite. Some people do their banking and finance in a specific browser. Some use a specific browser just for watching videos.

Which browser a person uses for which task is seemingly random. Maybe they were told to use a specific browser for one task, and then the other browser became the fallback. Maybe they once heard somewhere once that one browser was more secure. Maybe flash seemed broken on one browser when they were watching a video, and now a pattern has been set.

This has long seemed like an opportunity to me. Market a browser that actually claims to be the right browser for some of these purposes! Firefox has Developer Edition and it’s been reasonably successful.

This offers an opportunity for both Mozilla and Firefox users to agree on purpose. What is Firefox for? Everything! Is this feature meant for you? Unlikely! In a purpose-built browser both sides can agree what it’s trying to accomplish.

This idea often gets poo-pooed for how much work it is, but I think it’s simpler than it seems. Here’s what a “new browser” means:

Something you can find and download from its own page or site
It’s Firefox, but uses its own profile, keeping history/etc separate from other browser instances (including Firefox)
It has its own name and icon, and probably a theme to make it obvious what browser you are in
It comes with some browser extensions and prefs changed, making it more appropriate for the proposed use case

The approach is heavy on marketing and build tools, and light on actual browser engineering.

I also have gotten frequent feedback that Multi-Account Containers should solve all these use cases, but that gets everything backwards. People already understand multiple browsers, and having completely new entry points to bring people to Firefox is a feature, not a bug.

Sadly I think the time for this has passed, maybe in the market generally or maybe just for Mozilla. It would have been a very different approach to the browser.

Some of us in the Test Pilot team had some good brainstorming around actual concepts too, which is where I actually get excited about the ideas:

Firefox Study

For students, studying.

Integrate note-taking tools
Create project and class-based organizational tools, helping to organize tabs, bookmarks, and notes
Tools to document and organize deadlines
Citation generators

I don’t know what to do with online lectures and video, but it feels like there’s some meaningful improvements to be done in that space. Video-position-aware notetaking tools?

I think the intentionality of opening a browser to study is a good thing. iPads are somewhat popular in education, and I suspect part of that is having a device that isn’t built around multitasking, and using an iPad means stepping away from regular computing.

Firefox Media

To watch videos. This requires very few features, but benefits from just being a separate profile, history, and icon.

There’s a small number of features that might be useful:

Cross-service search (like Can I Stream.it or JustWatch)
Search defaults to video search
Cross-service queue
Quick service-based navigation

I realize it’s a lot like Roku in an app.

Firefox for Finance

This is really just about security.

Funny story: people say they value security very highly. But if Mozilla wants to make changes in Firefox that increase security but break some sites – particularly insecure sites – people will then stop using Firefox. They value security highly, but still just below anything at all breaking. This is very frustrating for us.

At the same time, I kind of get it. I’m dorking around on the web and I click through to some dumb site, and I get a big ol’ warning or a blank page or some other weirdness. I didn’t even care about the page or its security, and here my browser is trying to make me care.

That’s true some of the time, but not others. If you are using Firefox for Finance, or Firefox Super Secure, or whatever we might call it, then you really do care.

There’s a second kind of security implied here as well: security from snooping eyes and on shared computers. Firefox Master Password is a useful feature here. Generally there’s an opportunity for secure data at rest.

This is also a vehicle for education in computer security, with an audience that we know is interested.

Firefox Low Bandwidth

Maybe we work with proxy services. Or just do lots of content blocking. In this browser we let content break (and give a control to load the full content), so long as you start out compact.

Cache content that isn’t really supposed to be cached
Don’t load some kinds of content
Block fonts and other seemingly-unimportant content
Monitoring tools to see where bandwidth usage is going

Firefox for Kids

Sadly making things for kids is hard, because you are obliged to do all sorts of things if you claim to target children, but you don’t have to do anything if kids just happen to use your tool.

There is an industry of tools in this area that I don’t fully understand, and I’d want to research before thinking about a feature list. But it seems like it comes down to three things:

Blocking problematic content
Encouraging positive content
Monitoring tools for parents

There’s something very uninspiring about that list, it feels like it’s long on negativity and short on positive engagement. Coming up with an answer to that is not a simple task.

Firefox Calm

Inspired by a bunch of things:

What would a calm Firefox experience look like? Or maybe it would be better to think about a calm presentation of the web. At some point I wrote out some short pitches:

Read without distraction: Read articles like they are articles, not interactive (and manipulative) experiences.
Stay focused on one thing at a time: Instead of a giant list of tabs and alerts telling you what we aren’t doing, automatically focus on the one thing you are doing right now.
Control your notifications: Instead of letting any site poke at you for any reason, notifications are kept to a minimum and batched.
Focused writing: When you need to focus on what you are saying, not what people are saying to you, enter focused writing mode.
Get updates without falling down a news hole: Avoid clickbait, don’t reload pages, just see updates from the sites you trust (relates to Your Front Page)
Pomodoro: let yourself get distracted… but only a little bit. The Pomodoro technique helps you switch between periods of focused work and letting yourself relax
Don’t even ask: Do you want notifications from the news site you visited once? Do you want videos to autoplay? Of course not, and we’ll stop even asking.
Suggestion-free browsing: Every page you look at isn’t an invitation to tell you what you should look at next. Remove suggested content, and do what YOU want to do next. (YouTube example)

Concluding thoughts

Not just the conclusion of this list, the conclusion of my work in this area…

Some challenges in the design process:

Asking someone to do something new is hard, and unlikely to happen. My previous post (The Over-engaged Knowledge Worker) relates to this tension.
… and yet a “problem” isn’t enough to get someone to do something either.
If someone is consciously and specifically doing some task, then there’s an opportunity.
Creating wholistic solutions is unwelcome, unintuitively each thing that adds to the size of a solution diminishes from the breadth of problems the solution can solve.
… and yet, abstract solutions without any clear suggestion of what they solve aren’t great either!
Figuring out how to package functionality is a big deal.
Approaches that increase the density of information or choices are themselves somewhat burdensome.
… and yet context-sensitive approaches are unpredictable and distracting compared to consistent (if dense) functionality.
I still believe there’s a wealth of material in the content of the pages people encounter. But it’s irregular and hard to understand, it takes concerted and long-term effort to do something here.
Lots of the easy stuff, the roads well traveled, are still hard for a lot of people. Maybe this can be fixed by optimizing current UI… but I think there’s still room for novel improvements to old ideas.
User research is a really great place to start, but it’s not very prescriptive. It’s mostly problem-finding, not solution-finding.
There’s some kinds of user research I wish I had access to, specifically really low level analysis of behavior. What’s in someone’s mind when they open a new tab, or reuse one? In what order do they scan the UI? What are mental models of a URL, of pages and how they change, in what order to people compose (mentally and physically) things they want to share… it feels like it can go on forever, and there would be a ton of detail in the results, but given all the other constraints these insights feel important.
There’s so many variables in an experiment, that it’s hard to know what failures really means. Every experiment that offers a novel experience involves several choices, and any one choice can cause the experiment to fail.

As Test Pilot comes to an end, I do find myself asking: is there room for qualitative improvements in desktop browser UI? Desktop computing is waning. User expectations of a browser are calcified. The only time people make a choice is when something breaks, and the only way to win is to not break anything and hope you competitor does break things.

So, is there room for improvement? Of course there is! The millions of hours spent every day in Firefox alone… this is actually important. Yes, a lot of things are at a local maximum, and we can A/B test little tweaks to get some suboptimal parts to their local maximum. But I do not believe in any way that the browsers we know are the optimal container. The web is bigger than browsers, bigger than desktop or mobile or VR, and a user agent can do unique things beyond any site or app.

And yet…

Hack News Comments if that’s your thing.

The Over-engaged Knowledge Worker

2019-01-28T00:00:00-06:00

I recently listened to a discussion of knowledge work in the browser. Along the way people imagined idealized workflows and the tools that could enable them. This result felt familiar from concept videos since forever (such as this old Mozilla concept video):

The result featured lots of jet-setting highly engaged people deep in collaboration. For instance: Joe sends his friend a mortgage refinancing proposal to get feedback.

None of my friends have ever just blasted a mortgage refinancing proposal to me for a quick review. Thank god. But I’ve gotten similar requests, we all have, and nobody wants to receive these things. Usually the request sits guiltily in my inbox, mocking me and my purported friendship. If it’s job-related I will eventually get to even the work I loathe, but there’s always a particular pile of work that haunts me. This is not engagement.

This is the reality of knowledge work that none of these conceptualizations address: it’s hard (in very specific ways), some of it we don’t want to do, and the work we don’t want to do piles up and becomes dominant simply because it remains undone.

Our real work looks different than how we idealize our work: work items are smaller, less impactful, higher-touch, and collaboration spreads work out over time, decreasing personal engagement. We also imagine situations where people are much more actively engaged as a total percentage of their interactions, while we spend a lot of time passively receiving information, or simply deciding: what, if anything, should I react to?

So then what?

So how might we approach idea generation around knowledge work without idealizing the knowledge worker?

We could still go too far into acceptance. We’d build solitaire into the browser, the ultimate knowledge worker tool. It’s what people want! People shouldn’t have to pick up their phones to be distracted, we should keep the web as the universal distraction platform it was always meant to be. Oops, I make the mistake of thinking phone-vs-web, rather we should focus on providing distraction continuity across all your platforms. Sorry, this sarcasm is becoming uncomfortable…

I’m not sure a distraction tool is wrong. Giving people a mental break when they want it, but without trying to capture those people, could be positive. The web is full of mental breaks, but they aren’t “breaks”, they are manufactured to hold onto attention long after the needed break has finished.

But if we don’t build engagement tools (because people aren’t looking to be more engaged) and we don’t build distraction tools (because a web browser is already a sufficiently good distraction tool), what do we build?

I think there’s more opportunity in accepting the mentally fatigued and distracted state of knowledge workers, and working from that instead of against it. With that in mind I’d break down the problem into a few categories:

Reduce the drain of knowledge work, so that distractions are less necessary.
Support positive mental relaxation.
Support continuity of mental effort; make it easier to get back on track.

And I’d leave out:

Efficiency: usually efficiency means speed, number of steps, integrations, and so it calls for higher engagement. We care about efficiency, but only the efficient use of mental resources.
Blocking distractions: people want something out of distractions, and while we might aspire to replace distractions it’s probably unsustainable to block those distractions. Blocking is like starting an exercise plan by getting rid of all your chairs.
Communication and collaboration: even if distractions don’t break your continuity, collaboration will! Collaboration is obviously an interesting space, but you can’t do anything without pulling your collaborators into yet another tool. Trying to convert other people to a new way of working is not mentally relaxing.

Here’s where I throw my hands up and admit that I don’t have solutions to these problems, just a new problem statement.

But it does point in some different directions: how do we support a continuity of intention across a long task? In the context of the browser, how do we contextualize pages and interactions inside some abstract task? How do we clarify context? If the human is forced to multitask, can the multitasking tools be grounding instead of stretching us out?

The resulting exploration is not one that constructs an enviable user. It’s a user with virtual piles of papers on their desk with a PB&J forgetten a third of the way down, with a People Magazine placed sneakily inside an important report, with a pile of mail and every single piece is marked Urgent: Open Immediately. People aren’t always knolling… but maybe we could be.

Hacker News comments for the curious.

We Need Open Hosting Platforms

2019-01-23T00:00:00-06:00

In Bringing people back to the open web Chris states:

But most users don’t care about the principles or implementation of an open web, at least not in those terms. Most people don’t see themselves as ever having left the open web behind, and if you told them to try to get back to it, they wouldn’t know what to do or why it was worthwhile.

No matter how much it might be in their long-term self interest, it’s not up to the casual Internet user to figure that out. Instead, it’s up to the developers, designers, entrepreneurs and technology leaders to create a version of the open web that also happens to be the best version of the web.

I think he’s starting with a reasonable, positive call: we can’t just decry the state of things, we have to make things. And we have to make good things. The open web should be better.

I fear a moralizing approach to advocacy pushes people away, makes it harder for people to care about the values we are espousing. When we frame something as depressing or hopeless we encourage people to pay attention to other things. So yes: the open web should be the best web.

But ignoring my advice, I’m going to point out a depressing fact: open source products aren’t successful. Open source is not in line to be part of any solution.

Open Source has done a lot for developers, but it’s not present on the surface of the web – the surface that people interact with, and that defines the “open web”. Actual sites. Actual interfaces. Open source is used everywhere except at the point of interaction with actual people.

Why is open source so absent?

One big problem: the web isn’t software. The web is deployed software, running on servers.

If, as a creator of software, I want to share what I’ve done with everyone on the web – not just with other developers – then I actually have to deploy that software somewhere. But if maintaining open source is difficult and unsustainable, hosting that software is even worse.

I could create a whole company to support the service. But at that point I’m not a developer, I’m an “entrepreneur”. That’s more of a pain in the ass than giving stuff away.

For open source developers to build the open web we need a platform that allows us to actually give the tools we’ve created to everyone. Because of the hosting problem all our open source work is mediated through commercial entities, and we have this world where the web is very much built on open source, and yet that does nothing to make it more open.

An open hosting platform is not a specification, it is not a protocol, it is not a piece of software. It is actual hosting. It is people who deal with abuse, security, takedown notices, denial of service attacks, naming, bill paying, authentication and recovery, and are committed to ongoing improvements to the platform. Those are the things that separate software from a running service, and only running services can participate in the open web.

I don’t think decentralization, federation, or P2P is important or probably even desirable. I think these are ways to avoid the work of hosting, and they succeed to the degree no one uses the resulting software and so no work has to be done. It’s better to start with a working product.

Would hosting change things? Probably not enough: products aren’t just software, and open source development still struggles to include a diversity of skills and the consistent delivery of effort to make a product. Here, I have no suggestions. But still, an open, public, accessible hosting platform would be a start.

Thoughts on the Firefox Email Tabs experiment

2018-11-15T00:00:00-06:00

We recently released Email Tabs in Firefox Test Pilot. This was a project I championed, and I wanted to offer some context on it.

Email Tabs is a browser add-on that makes it easier to compose an email message from your tabs/pages. The experiment page describes how it works, but to summarize it from a technical point of view:

You choose some tabs
The add-on gets the best title and URL from the tab(s), makes a screenshot, and uses reader view to get simplified content from the tab
It opens a email compose page
It asks you what you want your email to look like (links, entire articles, screenshots)
It injects the HTML (somewhat brutally) into the email composition window
When the email is sent, if offers to close the compose window or all the tabs you’ve sent

It’s not fancy engineering. It’s just-make-it-work engineering. It does not propose a new standard for composing HTML emails. It doesn’t pay attention to your existing mail settings. It does not push forward the state of the art. It has no mobile component. Notably, no one in Mozilla ever asked us to make this thing. And yet I really like this add-on, and so I feel a need to explain why.

User Research origins

A long time ago Mozilla did research into Save/Share/Revisit. The research was based on interviews, journals, and directly watching people do work on their computers.

The results should not be surprising, but it was important to actually have them documented and backed up by research:

People use simple techniques
Everyone claims to be happy with their current processes
Everyone used multiple tools that typically fed into each other
Those processes might seem complicated and inefficient to me, but didn’t to them
People said they might be open to improvements in specific steps
People were not interested in revamping their overall processes
Some techniques were particularly popular:
Screenshots
URLs
Email
Texting
Bookmarks

Not everyone used all of these, but they were all popular.

The research made me change a page-freezing/saving tool (Page Shot) into what is now Firefox Screenshots (I didn’t intend to lose the freezing functionality along the way, but things happen when you ship).

Even if the research was fairly clear, it wasn’t prescriptive, and life moved on. But it sat in the back of my head, both email and the general question of workflows. And once I was doing less work on Screenshots I felt compelled to come back to it. Email stuck out, both because of how ubiquitous it was, and how little anyone cared about it. It seemed easy to improve on.

Email is also multipurpose. People will apologetically talk about emailing themselves something in order to save it, even though everyone does it. It can be a note for the future, something to archive for later, a message, a question, an FYI. One of the features of Email Tabs that I’m fond of is the ability to send a set of tabs, and then close those same tabs. Have a set of tabs that represent something you don’t want to forget, but don’t want to use right now? Send it to yourself. And unlike structured storage (like a bookmark folder), you can describe as much as you want about your next steps in the email itself.

Choosing to integrate with webmail

The obvious solution is to make something that emails out a page. A little web service perhaps, and you give it a URL and it fetches it, and then something that forwards the current URL to that service…

What seems simple becomes hard pretty quickly. Of course you have to fetch the page, and render it, and worry about JavaScript, and so on. But even if you skip that, then what email address will it come from? Do you integrate with a contact list? Make your own? How do you let people add a little note? A note per tab? Do you save a record?

Prepopulating an email composition answers a ton of questions:

All the mail infrastructure
From addresses, email verification, selecting your address, etc
To field, CC, address book
The editable body gives the user control and the ability to explain why they are sending something
It’s very transparent to the user what they are sending, and they confirm it by hitting Send

Since then I’ve come to appreciate the power of editable documents. Again it should be obvious, but there’s this draw any programmer will feel towards structured data and read-only representations of that data. The open world of an email body is refreshingly unconstrained.

Email providers & broken browsers

One downside to this integration is that we are shipping with only Gmail support. That covers most people, but it feels wrong.

This is an experiment, so keep it simple, right? And that was the plan until people from marketing kept asking over and over for us to support other clients and we thought: if they care so much maybe they are right.

We didn’t get support for other providers ready for launch, but we did get a good start on it. Along the way I saw that Yahoo Mail is broken and Outlook isn’t supported at all in Firefox (and the instructions point to a pretty unhelpful addons.mozilla.org search). That’s millions of users who aren’t getting a good experience.

Growing Firefox is a really hard problem. Of course Mozilla has also studied this quite a bit, and one of the strongest conclusions is that people change their browser when their browser breaks. People aren’t out there looking for something better, everyone has better things to do than think about their web browser. But if things don’t work people go searching.

But what does broken really mean? I suspect if we looked more closely we might be surprised. The simple answer: something is broken if it doesn’t act the way it should. But what “should” something do? If you click a link and Mail.app opens up, and you don’t use Mail.app, that’s broken. To Mozilla developers, if Mail.app is your registered default mail provider, then it “should” open up. Who’s right?

Email Tabs doesn’t offer particular insight into this, but I do like that we’ve created something with the purpose of enabling a successful workflow. Nothing is built to a spec, or to a standard, it’s only built to work. I think that process is itself revealing.

Listening to the research

Research requires interpretation. We asked questions about saving, sharing, and revisiting content, and we got back answers on those topics. Were those the right questions to ask? They seem pretty good, but there’s other pretty good questions that will lead to very different answers. What makes you worried when you use the web? What do you want from a browser? What do you think about Firefox? What do you use a browser for? What are you doing when you switch from a phone to a desktop browser? We’ve asked all these questions, and they point to different answers.

And somewhere in there you have to find an intersection between what you hear in the research and what you know how to do. There’s no right answer. But there is something different when you start from the user research, instead of using the user research. There’s a different sort of honesty to the conclusions, and I hope that comes through in the product.

I know what Email Tabs isn’t: it’s not part of any strategy. It’s not part of any kind of play for anything. There’s no ulterior motives. There’s no income potential. This makes its future very hazy. And it won’t be a blow-up success. It is merely useful. But I like it, and I hope we do more.

A Product Journal: Oops We Made A Scraper

2016-08-15T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

A while back we got our first contributor to PageShot, who contributed a feature he wanted for Outernet – the ability to use PageShot to create readable and packaged versions of websites for distribution. Outernet is a neat project: they are building satellite capacity to distribute content anywhere in the world. But it’s purely one-way, so any content you send has to be complete. And PageShot tries pretty hard to identify and normalize all that content.

Lately I spent a week with the Activity Stream team, and got to thinking about the development process around recommendations. I’d like to be able to take my entire history and actually get the content, and see what I can learn from that.

And there’s this feature in PageShot to do just that! You can install the add-on and enable the pref to make the browser into a server:

about:addons prefs

After that you can get the shot data from a page with a simple command:

$ url=https://mail.google.com
$ server=http://localhost:10082
$ curl "${server}/data/?url=${url}&allowUnknownAttributes=true&delayAfterLoad=1000" > data.json

allowUnknownAttributes preserves attributes like data-* attributes that you might find useful in your processing. delayAfterLoad gives the milliseconds to wait, usually for the page to “settle”.

A fun part of this is that because it’s in a regular browser it will automatically pick up your profile and scrape the page as you, and you’ll literally see a new tab open for a second and then close. Install an ad blocker or anything else and its changes will also be applied.

The thing you get back will be a big JSON object:

{
  "bodyAttrs": ["name", "value"],
  "headAttrs": [], "htmlAttrs": [],
  "head": "html string",
  "body": "html string",
  "resources": {
    "uuid": {
      "url": "..."
    }
  }
}

There’s other stuff in there too (e.g., Open Graph properties), but this is what you need to reconstruct the page itself. It has a few nice features:

The head and body are well formed; they are actually serialized from the DOM, not related to the HTTP response.
All embedded resources (mostly images) are identified in the resources mapping. The URLs in the page itself are replaced with those UUIDs, so you can put them back with a simple string substitutions, or you can rewrite the links easily.
Actual links (<a href>) should all be absolute.
It will try to tell you if the page is private (though it’s just a heuristic).
If you want, it’ll include a screenshot of the full page as a data: URL (use &thumbnailWidth=px to choose how wide).
CSS will be inlined in a <style> tag, perhaps reducing the complexity of the page for you.

Notably scripts and hidden elements will not be included (because PageShot was written to share visible content and not to scrape content).

Anyway, fun to realize the tool can address some hidden and unintentional use cases.

A Product Journal: Data Up and Data Down

2016-04-28T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

We’re in the process of reviewing the KPI (Key Performance Indicators) for Firefox Hello (relatedly I joined the Firefox Hello team as engineering manager in October). Mozilla is trying (like everyone else) to make data-driven decisions. Basing decisions on data has some potential to remove or at least reveal bias. It provides a feedback mechanism that can provide continuity even as there are personnel changes. It provides some accountability over time. Data might also provide insight about product opportunities which we might otherwise miss.

Enter the KPI: for Hello (like most products) the key performance indicators are number of users, growth in users over time, user retention, and user sentiment (e.g., we use the Net Promoter Score). But like most projects those are not actually our success criteria: product engagement is necessary but not sufficient for organizational goals. Real goals might be revenue, social or political impact, or improvement in brand sentiment.

The value of KPI is often summarized as “letting us know how we’re doing”. I think the value KPI offers is more select:

When you think a product is doing well, but it’s not, KPI is revealing.
When you know a product isn’t doing well, KPI let’s you triage: is it hopeless? Do we need to make significant changes? Do we need to maintain our approach but try harder?
When a product is doing well the KPI gives you a sense of the potential. You can also triage success: Should we invest heavily? Stay the path? Is there no potential to scale the success far enough?

I’m skeptical that KPI can provide the inverse of 1: when you think a product is doing poorly, can KPI reveal that it is doing well? Because there’s another set of criteria that defines “success”, KPI is necessary but not sufficient. It requires a carefully objective executive to revise their negative opinion about the potential of a project based on KPI, and they may have reasonably lost faith that a project’s KPI-defined success can translate into success given organizational goals.

The other theoretical value of KPI is that you could correlate KPI with changes to the product, testing whether each change improves your product’s core value. I’m sure people manage to do this, with both very fine grained measurements and fine grained deployments of changes. But it seems more likely to me that for most projects given a change in KPI you’ll simply have to say “yup” and come up with unverified theories about that change.

The metrics that actually support the development of the product are not “key”, they are “incidental”. These are metrics that find bugs in the product design, hint at unexplored opportunities, confirm the small wins. These are metrics that are actionable by the people making the product: how do people interact with the tool? What do they use it for? Where do they get lost? What paths lead to greater engagement?

What is KPI for?

I’m trying to think more consciously about the difference between managing up and managing down. A softer way of phrasing this is managing in and managing out – but in this case I think the power dynamics are worth highlighting.

KPI is data that goes up. It lets someone outside the project – and above the project – make choices: about investment, redirection, cancellation. KPI data doesn’t go down, it does little to help the people doing the work. Feeling joy or despair about your project based on KPI is not actionable for those people on the inside of a project.

Incentive or support

I would also distinguish two kinds of management here: one perspective on management is that the organization should set up the right incentives and consequences so that rewards are aligned with organizational goals. The right incentives might make people adapt their behavior to get alignment; how they adapt is undefined. The right incentives might also exclude those who aren’t in alignment, culling misalignment from the organization. Another perspective is that the organization should work to support people, that misalignment of purpose between a person and the organization is more likely a bug than a misalignment of intention. Are people black boxes that we can nudge via punishment and reward? Are there less mechanical ways to influence change?

Student performance measurement are another kind of KPI. It lets someone on the outside (of the classroom) know if things are going well or poorly for the students. It says little about why, and it doesn’t support improvement. School reform based on measurement presumes that teachers and schools are able to achieve the desired outcomes, but simply not willing. A risk of top-down reform: the people on the top use a perspective from the top. As an authority figure, how do I make decisions? The resulting reform is disempowering, supporting decisions from above, as opposed to using data to support the empowerment of those making the many day-to-day decisions that might effect a positive outcome.

Of course, having data available to inform decisions at all levels – from the executive to the implementor – would be great. But there’s a better criteria for data: it should support decision making processes. What are your most important decisions?

As an example from Mozilla, we have data about how much Firefox is used and its marketshare. How much should we pay attention to this data? We certainly don’t have the granularity to connect changes in this KPI to individual changes we make in the project. The only real way to do that is through controlled experiments (which we are trying). We aren’t really willing to triage the project; no one is asking “should we just give up on Firefox?” The only real choice we can make is: are we investing enough in Firefox, or should we invest more? That’s a question worth asking, but we need to keep our attention on the question and not the data. For instance, if we decide to increase investment in Firefox, the immediate questions are: what kind of investment? Over what timescale? Data can be helpful to answer those questions, but not just any data.

Exploratory data

Weeks after I wrote (but didn’t publish) this post I encountered Why Greatness Cannot Be Planned: The Myth of the Objective, a presentation by Kenneth Stanley:

“Setting an objective can block its own achievement. It can be an obstacle to creativity and innovation in general. Without protection of individual autonomy collaboration can become dangerously objective.”

The example he uses is manually searching a space of nonlinear image generation to find interesting images. The positive example is one where people explore, branching from novel examples until something recognizable emerges:

One negative example is one where an algorithm explores with a goal in mind:

Another negative example is selection by voting, instead of personal exploration; a product of convergent consensus instead of divergent treasure hunting:

If you decide what you are looking for, you are unlikely to find it. This generated image search space is deliberately nonlinear, so it’s difficult to understand how actions affect outcomes. Though artificial, I think the example is still valid: in a competitive environment, the thing you are searching for is hard to find, because if it was not hard then someone would have found it. And it’s probably hard because actions affect outcomes in unexpected ways.

You could describe this observation as another way of describing the pitfalls of hill climbing: getting stuck at local maximums. Maybe an easy fix is to add a little randomness, to bounce around, to see what lies past the hill you’ve found. But the hills themselves can be distractions: each hill supposes a measurement. The divergent search doesn’t just reveal novel solutions, but it can reveal a novel rubric for success.

This is also a similar observation to that in Innovator’s Dilemma: specifically that in these cases good management consistently and deliberately keeps a company away from novelty and onto the established track, and it does so by paying attention to the feedback that defines the company’s (current) success. The disruptive innovation, a term somewhat synonymous with the book, is an innovation that requires a change in metrics, and that a large portion of the innovation is finding the metric (and so finding the market), not implementing the maximizing solution.

But I digress from the topic of data. If we’re going to be data driven to entirely new directions, we may need data that doesn’t answer a question, doesn’t support a decision, but just tells us about things we don’t know. To support exploration, not based on a hypothesis which we confirm or reject based on the data, because we are still trying to discover our hypothesis. We use the data to look for the hidden variable, the unsolved need, the desire that has not been articulated.

I think we look for this kind of data more often than we would admit. Why else would we want complex visualizations? The visualizations are our attempt at finding a pattern we don’t expect to find.

In Conclusion

I’m lousy at conclusions. All those words up there are like data, and I’m curious what they mean, but I haven’t figured it out yet.

A Product Journal: CSS Object Model

2015-12-29T00:00:00-06:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

And now for something entirely technical!

We’ve had a contributor from Outernet exploring ways of using PageShot for capturing pages for distribution on their network. Outernet satellite-based content distribution network. It’s a neat idea, but one challenge is that it’s very one-way – anyone (given the equipment) can listen in to what the satellites broadcast, but that’s it (at least for the most interesting use cases). Lots of modern websites aren’t setup well for that, so acquiring content can be tricky.

Given that interest I started thinking more about inlining resources. We’ve been hotlinking to resources simply out of laziness. Some things are easy to handle, but CSS is a bit more annoying because of the indirection of @import and yet more relatively URLs. Until I started poking around I had no idea that there is a CSS Object Model!

Given this there is now experimental support for inlining all CSS rules into the captured page in PageShot. The support is still incomplete, and my understanding of everything you can do with CSS is still incomplete. But the code isn’t very hard. One fun thing is that we can test each CSS rule against the page and see if it is needed. Doing this typically allows 80% of rules to be omitted.

Some highlights of what I’ve learned so far:

There’s two interesting objects: CSSStylesheet (which inherits from Stylesheet) and CSSRule.

document.styleSheets: a list of all stylesheets, both remote (<link>), inline, and imported (@import) stylesheets.

styleSheet.href: the URL of the stylesheet (null if it was inline).

styleSheet.cssRules: a list of all the rules in the stylesheet.

cssRule.type: there’s several types of rules. I’ve chosen to ignore everything but STYLE_RULE and MEDIA_RULE out of laziness.

cssRule.cssRules: media rules (like @media (max-width: 600px) {.nav {display: none}}) contain sub-rules (.nav {display: none} in this case).

cssRule.parentRule: points back to a media rule if there is one.

cssRule.parentStyleSheet: points back to the parent stylesheet. There are probably ways of nesting media rules and stylesheets (that can have media attributes) in ways to create compound media rules that I haven’t accounted for.

cssRule.cssText: the text of the rule. This includes both selectors and style, or media queries and all the sub-rules. I just split on { to separate the selector or query. I assume these are representations of the parsed CSS, and so normalized, but I haven’t explored that in detail.

There’s all sorts of ways to create trees of media restrictions and other complexities that I know I haven’t taken account of, but things Mostly Work Anyway.

Here’s an example that makes use of this to create a single inline stylesheet for a page containing only necessary rules (using ES6):

let allRules = [];

// CSS rules, some of which may be media queries, form a kind of tree; this gets
// this puts all the style rules in a flat list
function addRules(sheet) {
  for (let rule of sheet.cssRules) {
    if (rule.type == rule.MEDIA_RULE) {
      addRules(rule);
    } else if (rule.type == rule.STYLE_RULE) {
      allRules.push(rule);
    }
  }
}

// Then we traverse all the stylesheets and grab rules from each:
for (let styleSheet of document.styleSheets) {
  if (styleSheet.media.length && styleSheet.media.indexOf("*") == -1 && styleSheet.media.indexOf("screen") == -1) {
    // This is a stylesheet for some media besides screen
    continue;
  }
  addRules(styleSheet);
}

// Then we collect the rules up again, clustered by media queries (with
// rulesByMedia[""] for no media query)
let rulesByMedia = {};

for (let rule of allRules) {
  let selector = rule.split("{")[0].trim();
  if (! document.querySelector(selector)) {
    // Skip selectors that don't match anything
    continue;
  }
  let mediaType = "";
  if (rule.parentRule && rule.parentRule.type == rule.MEDIA_RULE) {
    mediaType = rule.parentRule.cssText.split("{")[0].trim();
  }
  rulesByMedia[mediaType] = rulesByMedia[mediaType] || [];
  rulesByMedia.push(rule);
}

// Now we can create a new clean stylesheet:
let lines = [];
for (let mediaType in rulesByMedia) {
  if (mediaType) {
    lines.push(mediaType + " {");
  }
  for (let rule of rulesByMedia[mediaType]) {
    let padding = mediaType ? "  " : "";
    lines.push(padding + rule.cssText);
  }
  if (mediaType) {
    lines.push("}");
  }
}

let style = "<style>" + lines.join("\n") + "</style>";

Obviously there could be rules that apply to DOM elements that aren’t present right now but could be created. And I’m sure it’s omitting fonts and animations. But it’s fun to hack around with.

It might be fun to use this hooked up to mutation observers during your testing and find orphaned rules.

Conway’s Corollary

2015-08-27T00:00:00-05:00

Conway’s Law states:

organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations

I’ve always read this as an accusation: we are doomed to recreate the structure of our organizations in the structure of software projects. And further: projects cannot become their True Selves, cannot realize the most superior design, unless the organization is itself practically structureless. That only without the constraints of structure can the engineer make the truly correct choices. Michelangelo sculpted from marble, a smooth and uniform stone, not from an aggregate, where any hit with the chisel might reveal only the chaotic structure and fault lines of the rock and not his vision.

But most software is built, not revealed. I’m starting to believe that Conway’s observation is a corollary, not so clearly cause-and-effect. Maybe we should work with it, not struggle against it. (With age I’ve lost the passion for pointless struggle.) It’s not that developers can’t imagine a design that goes contrary to the organizational structure, it’s that they can’t ship those designs. What we’re seeing is natural selection. And when through force of will such a design is shipped, that it survives and is maintained depends on whether that the organization changed in the process, whether a structure was created to support that design.

A second skepticism: must a particular construction and modularity of code be paramount? Code is malleable, and its modularity is for the purpose of humans. Most of what we do disappears anyway when the machine takes over – functions are inlined, types erased, the pieces become linked, and the machine doesn’t care one whit about everything we’ve done to make the software comprehensible. Modularity is to serve our purposes. And sometimes organization structure serves a purpose; we change it to meet goals, and we shouldn’t assume the people who change it are just busybodies. But those changes are often aspirational, and so those changes are setting ourselves up for conflict as the new structure probably does not mirror the software design.

If the parts of an organization (e.g. teams, departments, or subdivisions) do not closely reflect the essential parts of the product, or if the relationship between organizations do not reflect the relationships between product parts, then the project will be in trouble… Therefore: Make sure the organization is compatible with the product architecture – Coplien and Harrison

So change the architecture! There’s more than one way to resolve these tensions.

A last speculation: as described in the Second System Effect we see teams rearchitect systems with excessive modularity and abstraction. Maybe because they remember all these conflicts, they remember all the times organizational structure and product motivations didn’t match architecture. The team makes an incorrect response by creating an architecture that can simultaneously embody all imagined organizational structures, a granularity that embodies not just current organizational tensions but also organizational boundaries that have come and gone. But the value is only in predicting future changes in structure, and only then if you are lucky.

Maybe we should look at Conway’s Law as a prescription: projects should only have hard boundaries where there are organizational boundaries. Soft boundaries and definitions still exist everywhere: just like we give local variables meaningful names (even though outside the function no one can tell the difference), we might also create abstractions and modularity that serve immediate and concrete purposes. But they should only be built for the moment and the task at hand. Extra effort should be applied to being ready to refactor in the future, not predicting and embodying those predictions in present modularity. Perhaps this is another rephrasing of Agile and YAGNI. Code is a liability, agency over that code is an asset.

A Product Journal: Objects

2015-07-16T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

I’ve been reading the Early History Of Smalltalk, notes by Alan Kay, and this small note jumped out at me:

Another late-binding scheme that is already necessary is to get away from direct protocol matching when a new object shows up in a system of objects. In other words, if someone sends you an object from halfway around the world it will be unusual if it conforms to your local protocols. At some point it will be easier to have it carry even more information about itself–enough so its specifications can be “understood” and its configuration into your mix done by the more subtle matching of inference.

[…]

This higher computational finesse will be needed as the next paradigm shift–that of pervasive networking–takes place over the next five years. Objects will gradually become active agents and will travel the networks in search of useful information and tools for their managers. Objects brought back into a computational environment from halfway around the world will not be able to configure themselves by direct protocol matching as do objects today. Instead, the objects will carry much more information about themselves in a form that permits inferential docking. Some of the ongoing work in specification can be turned to this task.

An object, sent over the network; it does not exactly have a common protocol, class, or API, but enough information so it can be understood, matched up with some function or purpose according to inference. We could also assume given this is from Alan Kay that the vision here is that code, not just data, is part of the object and information (though to consider code to be information: that is quite a challenge to our modern sensibilities).

When I read this, it struck me that we have these objects all around us. The web page: remote, transferable, transformable, embodying functionality and data, with rich information suitable for inference.

The web page has a kind of minimal protocol, though nothing is entirely forbidden in how it is interpreted. For instance the page is named in its <title>. But probably it has a better name in its <meta name=og:title>, should one exist; nothing is truly formal except by how it will be conventionally interpreted. The protocol is flexible. It has internal but opaque state. The object can initiate activity in a few ways, primarily XMLHttpRequest and a small number of APIs available to it. The page receives copious input in the form of events.

It’s an impoverished object in so many ways. And it’s hardly what you would call universal, it’s always representing visual pages for the browser. When programming if the browser isn’t our intended audience then we choose something like JSON or REST: one dead data, one a possessed and untransferable object (I would assert that in REST the object is the server and not the document).

And yet the web page is an incredible object! Web pages are sophisticated and well cared for. Our understanding of them is meticulously documented, including the ambiguity. The web stack is something that has not just been “defined” or “fixed”, but also discovered. Web pages contain gateways into a tremendous number of systems, defined around a surprisingly small set of operations.

But we don’t look at them as objects, we don’t try to deduce or infer much about them. They don’t look like the objects we would define were we to design such a system. But if we shift our gaze from design to discovery then the wealth becomes apparent: these might not be the objects we would ask for, but given the breadth and comprehensiveness of web pages they are the objects we should use. And they actually work, they do a ton of useful things.

Stepping back from the specific product of PageShot, this is the broad direction that excites me: to understand and make use of these objects that are all around us. (Objects to which Mozilla, with its user agent, has unique access.) But we need to look more broadly at what we can do with these objects. PageShot tries one fairly small thing: capture the visual state at one moment, maybe do something with that state. If we just had a handful of these operations, exposed properly (not trapped in the depths of monolithic browsers) I think there are some incredible things to be done. Maybe even a way to bridge from the ad hoc to something more formal; as crazy as the web page execution model seems, it has some nice features, and is the widest deployed sandboxing execution model we have.

In this sense Web Assembly and ASM.js are interesting as effectively competitors to JavaScript, but not competitors to the web platform or web-page-as-object. That makes them different from Google Native Client. Yes, Web Assembly is essentially another language for the web platform. But Native Client uses Pepper which is not the web platform, it’s a parallel platform that attempts to mimic the web platform. ASM.js and Web Assembler are a demonstrations that we can change significant parts of the code execution while retaining the outward API of these pages.

I find this all exciting, but I am somewhat half-hearted in my excitement. Reading The Early History Of Smalltalk there’s a certain spirit to their work that I love and often despair at recreating. There is a visionary aspect, but I think more importantly they took a holistic approach. There’s something exciting about opening your mind to far off concepts (a vision) but then try to tie them together creatively, trying different approaches in an effort to maintain simplicity, avoid compromises. The computing systems they worked on were like Microworlds of their own creation, they could redefine problems, throw away state, reinvent any interface they chose. And maybe that is also available to us: only when we hopelessly despair about problems we cannot fix are we trapped by our legacy. That is, if you accept the web as it is there is a freedom, an agency in that, because you’ve put aside the things you can’t change.

I suspect Alan Kay would take a dim view of this whole notion. He is not a fan of the web. Another observation from that history:

Four techniques used together—persistent state, polymorphism, instantiation, and methods-as-goals for the object—account for much of the power. None of these require an “object-oriented language” to be employed—ALGOL 68 can almost be turned to this style—an OOPL merely focuses the designer’s mind in a particular fruitful direction. However, doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming.

I can’t even begin to phrase web pages in these terms. State is a mess: much hosted on remote servers, some in the URL, some in the process of the running page, some in cookies or localStorage, all of it constantly being copied and thrown away. Is the URL the class and the HTML served over HTTP the instantiation? These are just painful contortions to find analogs. Methods-as-goals is the one that seems most interesting and challenging, because I cannot quite identify the goals behind this whole endeavour. Automation? Insight? Detection? Creation? Is it different from what Google is doing with its spiders? Is there something distinct about interpretation in the context of a user agent? And when the objects are not willing – I am proposing we bend pages to our will, wrestling control from the expectations of site owners – can you do any delegation? Is there an object waiting to be smithed that encapsulates the page?

More tensions than resolutions. Wish I had time to bathe in those tensions a bit longer.

A Product Journal: Community Participation

2015-05-13T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

Generally at Mozilla we want to engage and activate our community to further what we do. Because all our work is open source, and we default to open on our planning, we have a lot of potential to include people in our work. But removing barriers to participation doesn’t make participation happen.

A couple reasons it’s particularly challenging:

Volunteers and employees work at different paces. Employees can devote more time, and can have pressures to meet deadlines so that sometimes the work just needs to get done. So everything is going fast and a volunteer can have a hard time keeping up. Until the project is cancelled and then wham, the employees are all gone.
Employees become acclimated to whatever processes are asked of them, because whether they like it or not that’s the expectation that comes with their paycheck. Sometimes employees put up with stupid shit as a result. And sometimes volunteers aren’t willing to make investments to their process even when it’s the smart thing to do, ‘cause who knows how long you’ll stick around?
Employee work has to satisfy organizational goals. The organization can try to keep these aligned with mission goals, and keep the mission aligned with the community, but when push comes to shove the organization’s goals – including the goals that come from the executive team – are going to take priority for employees.
Volunteers are unlikely to be devoted to Mozilla’s success. Instead they have their own goals that may intersect with Mozilla’s. This overlap may only occur on one project. And while that’s serendipitous, limited overlap means a limit on the relationships those volunteers can build, and it’s the relationships that are most likely to retain and reward participation.

I have a theory that agency is one of the most important attractors to open source participation. Mozilla, because of its size and because it has a corporate structure, does not offer a lot of personal agency. Though in return it does offer some potential of leverage.

I am not sure what to do with respect to participation in PageShot. If I open things up more, will anyone care? What would people care about? Maybe people would care about building a product. Maybe the building blocks would be more interesting. We have an IRC channel, but we also meet regularly over video, which I think has been important for us to assimilate the concept and goals of the project. Are there other people who would care to show up?

I’m also somewhat conflicted about trying to bring people in. Where will PageShot end up? The project could be cancelled. It’s open source, sure, but is it interesting as open source if it’s a deadend addon with no backing site? Our design is focused on making something broadly appealing such that it could be included in the browser – and if things go well, the addon will be part of the browser itself. If that happens (and I hope it will!) even my own agency with respect to the project will be at threat. That’s what it means to get organizational support.

If the project was devolved into a set of libraries, it would be easier to contribute to, and easier for volunteers to find value in their participation. Each piece could be improved on its own, and can live on even if the product that inspired the library does not continue. People who use those libraries will maintain agency, because they can remix those libraries however they want, include them in whatever product of their own conception that they have. The problem: I don’t care about the libraries! And I don’t want this to be a technology demonstration, I want it to be a product demonstration, and libraries shift the focus to the wrong part.

Despite these challenges, I don’t want to give up on the potential of participation. I just doubt would look like normal open source participation. I’ve expanded our participation section, including an invitation to our standup meetings. But mostly I need to know if anyone cares, and if you do: what do you care about and what do you want from your participation?

A Product Journal: As We May Discuss

2015-05-08T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

In a presentation The Revolution Will Be Annotated, Dan Whaley begins with a very high-minded justification for annotation: that it is essential for our existence that we act wisely, and that we can achieve that through deliberation, and that annotation is a building block for open deliberation.

In response, let me digress wildly, and talk about elementary school.

It is common to cite large class sizes as a problem, and small class sizes as an opportunity to improve education. But there is debate about whether class size really matters; it certainly correlates with general privilege, but does it cause improvements? At the same time I’ve become much more familiar with the Montessori philosophy of education, and one of the surprising features is a relatively large ideal classroom size, in the 30s. And why? Dr. Montessori had positive theories about age mixture, community size, the culture of the classroom, and so forth – but I’ll add what I think is a Montessori-style reason it’s okay: it’s okay to have less teachers because learning isn’t caused by teachers. Learning is ultimately an internal process, an assimilation and construction of knowledge. Your environment can aid in that process, but the cause is still internal.

I share Dan’s enthusiasm about the importance of dialog to our collective wisdom. But I see dialog as supportive of personal growth, not of collective wisdom – our collective wisdom will increase as we individually grow.

Dan cites one problem with rationalism: we are good at constructing rational arguments to support what we already believed. The annotation remedy is to suppose that what we conveniently leave out of our arguments can be applied later by a diverse set of participants. Annotation makes it harder to make use of fallacies, harder to make use of limited narratives, because the annotator can add them back in.

I will cite another problem with rationalism: even a good rational argument is not good at convincing anyone of anything. A good rational argument is like teaching arithmetic by telling someone that 39301+9402=48703. Maybe even writing out the steps used to make that calculation. You can lay that in front of someone, you can lay a hundred similar examples in front of someone, and they will not learn arithmetic. If the person is disinterested they can just trust you – though then it hardly matters if you were right – but if they are interested I believe that the process of construction is necessary. You have to solve your own math problems to learn math.

Annotation is interesting because it gives another avenue for people to publish their beliefs and enter into dialog. But a global overlay of annotation is not a particularly appealing medium. It’s not a place to come to understanding, to practice the construction of ideas. And I think our collective wisdom depends on an incredible volume of discussion, not just on an increased quality, because you can’t get large scale individual growth without large scale discussion.

I see two features in the typical annotation system: one feature is the ability to talk about other things, with high fidelity. URLs have been a great start to being able to talk about things on the web, but they have some limits. The second feature is the ability to view these annotations implicitly. The second feature is the one I’ve seldom found interesting as a reader, and disagree with as a goal. Viewing annotations as a universal overlay of commentary asks too much of the annotations, provides too little to me as the reader, and I think is an attempt to pursue a kind of rational universal truth that I find little value in. It’s a sense that documents are there to teach us, and annotations make those documents even better teachers.

PageShot takes a different approach: it gives anyone the ability to talk about anything on the web, but each time you do that you create a new resource, your discussion lives at your document. You can write your commentary for a specific audience, and then give it to that audience, without having your intended audience confused with the original author’s intended audience. You can throw away what you have to say. The person who clicks on your link did it to see what you said, they aren’t some passerby. You can say implicitly through highlighting, here is what I thought was interesting. But PageShot applies no universality to what you say, it is a tool only of dialog. This makes PageShot more modest, but intentionally so.

A Product Journal: As A Building Block

2015-04-23T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

I teeter between thinking big about PageShot and thinking small. The benefit of thinking small is: how can this tool provide value to people who wouldn’t know if it would provide any value? And: how do we get it done?

Still I can’t help but thinking big too. The web gave us this incredible way to talk about how we experience the web: the URL. An incredible amount of stuff has been built on that, search and sharing and archiving and ways to draw people into content and let people skim. Indexes, summaries, APIs, and everyone gets to mint their own URLs and accept anyone else’s URLs, pointing to anything.

But not everyone gets to mint URLs. Developers and site owners get to do that. If something doesn’t have a URL, you can’t point to it. And every URL is a pointer, a kind of promise that the site owner has to deliver on, and sometimes doesn’t choose to, or they lose interest.

I want PageShot to give a capability to users, the ability to address anything, because PageShot captures the state of any page at a moment, not an address so someone else can try to recreate that page. The frozen page that PageShot saves is handy for things like capturing or highlighting parts of the page, which I think is the feature people will find attractive, but that’s just a subset of what you might want to do with a snapshot of web content. So I also hope it will be a building block. When you put content into PageShot, you will know it is well formed, you will know it is static and available, you can point to exact locations and recover those locations later. And all via a tool that is accessible to anyone, not just developers. I think there are neat things to be built on that. (And if you do too, I’d be interested in hearing about your thoughts.)

A Product Journal: What Are We Making?

2015-04-21T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

I’ve managed to mostly avoid talking about what we’re making here. Perhaps shyness, we (the PageShot team) don’t yet know where it’s going, or if we’ll manage to get this into Firefox.

We are making a tool for sharing on the web. This tool creates a new kind of thing to share, it’s not a communication medium of any kind. We’re calling it PageShot, similar to a screenshot but with all the power we can add to it since web pages are much more understandable than pixels. (The things it makes we call a Shot.)

The tool emphasizes sharing clips or highlights from pages. These can be screenshots (full or part of the screen) or text clippings. Along with those clips we keep an archival copy of the entire web page, preserving the full context of the page you were looking at and the origin of each clip. Generally we try to save as much information and context about the page as we can. We are trying to avoid choices, the burdensome effort to decide what you might want in the future. The more effort you put into using this tool, the more information or specificity you can add to your Shot, but we do what we can to save everything so you can sort it out later if you want.

I mentioned earlier that I started this idea thinking about how to make use of frozen copies of the DOM. What we’re working on now looks much more like a screenshotting tool that happens to keep this copy of the page. This changed happened in part because of user research done at Mozilla around saving and sharing, where I became aware of just how prevalent screenshots had become to many people.

The current (rough) state of the tool

It’s not hard to understand the popularity of screenshots, specifically on mobile devices. iPhone users at least have mostly figured out screenshotting, functionality that remains somewhat obscure on desktop devices (and for the life of me I can’t get my Android device to make a screenshot). Also screenshots are the one thing that works across applications – even with an application that supports sharing, you don’t really know what’s going to be shared, but you know what the screenshot will contain. You can also share screenshots with confidence: the recipient won’t have to log in or sign up, they can read it on any device they want, once it has arrived they don’t need a network connection. Screenshots are a reliable tool. A lesson I try to regularly remind myself of: availability beats fidelity.

In a similar vein we’ve seen the rise of the animated gif over the video (though video resurging now that it’s just a file again), and the smuggling in of long texts to Twitter via images.

A lot of this material moves through communication mediums via links and metadata, but those links and metadata are generally under the control of site owners. It’s up to the site owner what someone sees when they click a link, it’s up to them what the metadata will suggest go into the image previous and description. PageShot gives that control to the person sharing, since each Shot is your link, your copy and your perspective.

As of this moment (April 2015) our designs are still ahead of our implementation, so there’s not a lot to try out at this moment, but this is what we’re putting together.

If you want to follow along, check out the repository.

A Product Journal: The Evolutionary Prototype

2015-03-20T00:00:00-05:00

I’m blogging about the development of a new product in Mozilla, look here for my other posts in this series

I came upon a new (for me) term recently: evolutionary prototyping. This is in contrast to the rapid or throwaway prototype.

Another term for the rapid prototype: the “close-ended prototype.” The prototype with a sunset, unlike the evolutionary prototype which is expected to become the final product, even if every individual piece of work will only end up as disposable scaffolding for the final product.

The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it.

The first version of the product, written primarily late at night, was definitely a throwaway prototype. All imperative jQuery UI and lots of copy-and-paste code. It served its purpose. I was able to extend that code reasonably well – and I played with many ideas during that initial stage – but it was unreasonable to ask anyone else to touch it, and even I hated the code when I had stepped away from it for a couple weeks. So most of the code is being rewritten for the next phase.

To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest.

Thinking about this, it’s a lot like the Minimal Viable Product approach. Of which I am skeptical. And maybe I’m skeptical because I see MVP as reductive, encouraging the aggressive stripping down of a product, and in the process encouraging design based on conventional wisdom instead of critical engagement. When people push me in that direction I get cagey and defensive (not a great response on my part, just acknowledging it). The framing of the evolutionary prototype feels more humble to me. I don’t want to focus on the question “how can we most quickly get this into users hands?” but instead “what do we know we should build, so we can collect a fuller list of questions we want to answer?”

A Product Journal: As A Working Manager

2015-03-10T00:00:00-05:00

One of the bigger changes going from engineer to manager was to redefine what I meant by the question: how are we going to do this? As an engineer I would deconstruct that question to ask what is the software we need to build, and the technical barriers we need to remove, to achieve our goals. As a manager I would deconstruct that question to ask what is the process by which we achieve our goals.

When I wear my manager hat and ask “how are we going to do this?” I get a little frustrated when I get the answer “I don’t know.” But that’s unfair – there are always problems to which we do not know the answer. What makes me frustrated is when the answer comes too quick, when someone says “I don’t know” because they are missing something they feel they need to come up with an answer. I don’t know because we have to write more code before we know if the idea is feasible. I don’t know because the decision is someone else’s, and so on.

You know! If the decision is someone else’s, then the answer to the question is: we are going to do this by asking that other person what they want and how they are going to make that decision. If we don’t know if the idea is feasible, then the answer to the question is: we are going to do this by exploring the feasibility of this technique, and doing another iteration of planning once we know more. “I don’t know because…” is fine because it is an answer of sorts, it lets the team make an answer in the form of a process. “I don’t know.” – ended with a period – is even okay for a moment, if you treat it as meaning “I don’t know so we are going to do this by learning.” It’s the “I don’t know, let’s move on” that I don’t like.

But I’m being a little unfair. It’s my job as a manager to answer at the process level. While I try very hard not to pigeonhole people, maybe I should also work harder at accepting when people establish bounds to their role. When you are trying to produce it can make sense to stay focused, to resist going meta. When you are working in a team, you should rely on the diverse skills of your teammates to let go of certain parts of the project. It can be okay to go heads-down. (Sometimes; and sometimes everyone on the team must lift their heads and respond to circumstance.)

This is a long-winded way of saying that I appreciate more of the difference in perspective of an engineer and a manager. It’s hard to hold both perspectives at once, and harder still to act on both.

In my new project I am returning to development, and entering into the role of working manager, an odd way to say that I am performing the same tasks that I am also managing. I cut myself off from programming when I started management so that I would not let myself be distracted from a new role and the considerable learning I had to do. Returning to programming, I can tell I was right to do so.

Moving between these two mindsets, and two very different ways of working, is challenging. In both I want to be proactive, but as a manager towards people, and as an engineer towards code. With people I’m investing my time in small chunks, trying to keep a good velocity of communication, watching for dropped balls, and the payoffs are largely indirect and deferred. With code it takes time to navigate my next task, I want to focus, I’m constantly trying to narrow that focus. And the payoff is direct and immediate: working code. This narrowed focus is a way to push forward much more reliably, so long as I know which way is forward.

But I’m a working manager. Is now the right time to investigate that odd log message I’m seeing, or to think about who I should talk to about product opportunities? There’s no metric to compare the priority of two tasks that are so far apart.

If I am going to find time to do development I am a bit worried I have two options:

Keep doing programming after hours
Start dropping some balls as a manager

I’ve been doing a little of both. To mitigate the effect of dropping balls I’ve tried my best to be transparent about this. It may have been effective: I am not doing my best work on X, because I’m trying to do my best work on Y. But I won’t really know if this has worked until later, turnaround on relationship feedback takes a while.

An aside: I’ve been learning a bit about Objectives and Key Results, a kind of quarterly performance analysis structure, and I particularly appreciate how it asks people to attempt to achieve 70% of their identified goals, not 100%. If you commit to 100% then you’ve committed yourself to a plan you made at the beginning of the quarter. You’ve erased your agency to prioritize.

Anyway, onward and upward, and wish me luck in letting the right balls drop.

A Product Journal: Building for a Demo

2015-02-18T00:00:00-06:00

I’ve been trying to work through a post on technology choices, as I had it in my mind that we should rewrite substantial portions of the product. We’ve just upped the team size to two, adding Donovan Preston, and it’s an opportunity to share in some of these decisions. And get rid of code that was desperately expedient. The server is only 400ish lines, with some significant copy-and-paste, so we’re not losing any big investment.

Now I wonder if part of the danger of a rewrite isn’t the effort, but that it’s an excuse to go heads-down and starve your situational awareness.

In other news there has been a major resignation at Mozilla. I’d read into it largely what Johnathan implies in his post: things seem to be on a good track, so he’s comfortable leaving. But the VP of Firefox can’t leave without some significant organizational impact. Now is an important time for me to be situationally aware, and for the product itself to show situational awareness. The technical underpinnings aren’t that relevant at this moment.

So instead, if only for a few days, I want to move back into expedient demoable product mode. Now is the time to explain the product to other people in Mozilla.

The choices this implies feel weird at times. What is most important? Security bugs? Hardly! It needs to demonstrate some things to different stakeholders:

There are some technical parts that require demonstration. Can we freeze the DOM and produce something usable? Only an existence proof is really convincing. Can we do a login system? Of course! So I build out the DOM freezing and fix bugs in it, but I’m preparing to build a login system where you type in your email address. I’m sure you wouldn’t lie so we’ll just believe you are who you say you are.
But I want to get to the interesting questions. Do we require a login for this system? If not, what can an anonymous user do? I don’t have an answer, but I want to engage people in the question. I think one of the best outcomes of a demo is having people think about these questions, offer up solutions and criticisms. If the demo makes everyone really impressed with how smart I am that is very self-gratifying, but it does not engage people with the product, and I want to build engagement. To ask a good question I do need to build enough of the context to clarify the question. I at least need fake logins.
I’ve been getting design/user experience help from Bram Pitoyo too, and now we have a number of interesting mockups. More than we can implemented in short order. I’m trying to figure out how to integrate these mockups into the demo itself — as simple as “also look at this idea we have”. We should maintain a similar style (colors, basic layout), so that someone can look at a mockup and use all the context that I’ve introduced from the live demo.
So far I’ve put no effort into onboarding. A person who picks up the tool may have no idea how it is supposed to be used. Or maybe they would figure it out: I haven’t even thought it through. Since I know how it works, and I’m doing the demo, that’s okay. My in-person narration is the onboarding experience. But even if I’m trying to explain the product internally, I should recognize I’m cutting myself off from an organic growth of interest.
There are other stakeholders I keep forgetting about. I need to speak to the Mozilla Mission. I think I have a good story to tell there, but it’s not the conventional wisdom of what it means to embody the mission. I see this as a tool of direct outward-facing individual empowerment, not the mediated power of federation, not the opting-out power of privacy, not the committee-mediated and developer driven power of standards.
Another stakeholder: people who care about the Firefox brand and marketing our products. Right now the tool lacks any branding, and it would be inappropriate to deploy this as a branded product right now. But I can demo a branded product. There may also be room to experiment with a call to action, and to start a discussion about what that would mean. I shouldn’t be afraid to do it really badly, because that starts the conversation, and I’d rather attract the people who think deeply about these things than try to solve them myself.

So I’m off now on another iteration of really scrappy coding, along with some strategic fakery.

A Product Journal: To MVP Or Not To MVP

2015-01-27T00:00:00-06:00

I’m going to try to journal the process of a new product that I’m developing in Mozilla Cloud Services. My previous post was The Tech Demo, and the first in the series is Conception.

The Minimal Viable Product

The Minimal Viable Product is a popular product development approach at Mozilla, and judging from Hacker News it is popular everywhere (but that is a wildly inaccurate way to judge common practice).

The idea is that you build the smallest thing that could be useful, and you ship it. The idea isn’t to make a great product, but to make something so you can learn in the field. A couple definitions:

The Minimum Viable Product (MVP) is a key lean startup concept popularized by Eric Ries. The basic idea is to maximize validated learning for the least amount of effort. After all, why waste effort building out a product without first testing if it’s worth it.

“”“– from How I built my Minimum Viable Product (emphasis in original)”“”

I like this phrase “validated learning.” Another definition:

A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible. Once the MVP is established, a startup can work on tuning the engine. This will involve measurement and learning and must include actionable metrics that can demonstrate cause and effect question.

“”“– Lean Startup Methodology (emphasis added)”“”

I don’t like this model at all: “once the MVP is established, a startup can work on tuning the engine.” You tune something that works the way you want it to, but isn’t powerful or efficient or fast enough. You’ve established almost nothing when you’ve created an MVP, no aspect of the product is validated, it would be premature to tune. But I see this antipattern happen frequently: get an MVP out quickly, often shutting down critically engaged deliberation in order to Just Get It Shipped, then use that product as the model for further incremental improvements. Just Get It Shipped is okay, incrementally improving products is okay, but together they are boring and uncreative.

There’s another broad discussion to be had another time about how to enable positive and constructive critical engagement around a project. It’s not easy, but that’s where learning happens, and the purpose of the MVP is to learn, not to produce. In contrast I find myself impressed by the shear willfulness of the Halflife development process which apparently involved months of six hour design meetings, four days a week, producing large and detailed design documents. Maybe I’m impressed because it sounds so exhausting, a feat of endurance. And perhaps it implies that waterfall can work if you invest in it properly.

Plan plan plan

I have a certain respect for this development pattern that Dijkstra describes:

Q: In practice it often appears that pressures of production reward clever programming over good programming: how are we progressing in making the case that good programming is also cost effective?

A: Well, it has been said over and over again that the tremendous cost of programming is caused by the fact that it is done by cheap labor, which makes it very expensive, and secondly that people rush into coding. One of the things people learn in colleges nowadays is to think first; that makes the development more cost effective. I know of at least one software house in France, and there may be more because this story is already a number of years old, where it is a firm rule of the house, that for whatever software they are committed to deliver, coding is not allowed to start before seventy percent of the scheduled time has elapsed. So if after nine months a project team reports to their boss that they want to start coding, he will ask: “Are you sure there is nothing else to do?” If they say yes, they will be told that the product will ship in three months. That company is highly successful.

“”“– from Interview Prof. Dr. Edsger W. Dijkstra, Austin, 04–03–1985“”“

Or, a warning from a page full of these kind of quotes: “Weeks of programming can save you hours of planning.” The planning process Dijkstra describes is intriguing, it says something like: if you spend two weeks making a plan for how you’ll complete a project in two weeks then it is an appropriate investment to spend another week of planning to save half a week of programming. Or, if you spend a month planning for a month of programming, then you haven’t invested enough in planning to justify that programming work – to ensure the quality, to plan the order of approach, to understand the pieces that fit together, to ensure the foundation is correct, ensure the staffing is appropriate, and so on.

I believe “Waterfall Design” gets much of its negative connotation from a lack of good design. A Waterfall process requires the design to be very very good. With Waterfall the design is too important to leave it to the experts, to let the architect arrange technical components, the program manager to arrange schedules, the database architect to design the storage, and so on. It’s anti-collaborative, disengaged. It relies on intuition and common sense, and those are not powerful enough. I’ll quote Dijkstra again:

The usual way in which we plan today for tomorrow is in yesterday’s vocabulary. We do so, because we try to get away with the concepts we are familiar with and that have acquired their meanings in our past experience. Of course, the words and the concepts don’t quite fit because our future differs from our past, but then we stretch them a little bit. Linguists are quite familiar with the phenomenon that the meanings of words evolve over time, but also know that this is a slow and gradual process.

It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar. Under sufficiently slow and gradual change, it works reasonably well; in the case of a sharp discontinuity, however, the method breaks down: though we may glorify it with the name “common sense”, our past experience is no longer relevant, the analogies become too shallow, and the metaphors become more misleading than illuminating. This is the situation that is characteristic for the “radical” novelty.

Coping with radical novelty requires an orthogonal method. One must consider one’s own past, the experiences collected, and the habits formed in it as an unfortunate accident of history, and one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate. One has, with initially a kind of split personality, to come to grips with a radical novelty as a dissociated topic in its own right. Coming to grips with a radical novelty amounts to creating and learning a new foreign language that can not be translated into one’s mother tongue. (Any one who has learned quantum mechanics knows what I am talking about.) Needless to say, adjusting to radical novelties is not a very popular activity, for it requires hard work. For the same reason, the radical novelties themselves are unwelcome.

“”“– from EWD 1036, On the cruelty of really teaching computing science“”“

Research

All this praise of planning implies you know what you are trying to make. Unlikely!

Coding can be a form of planning. You can’t research how interactions feel without having an actual interaction to look at. You can’t figure out how feasible some techniques are without trying them. Planning without collaborative creativity is dull, planning without research is just documenting someone’s intuition.

The danger is that when you are planning with code, it feels like execution. You can plan to throw one away to put yourself in the right state of mind, but I think it is better to simply be clear and transparent about why you are writing the code you are writing. Transparent because the danger isn’t just that you confuse your coding with execution, but that anyone else is likely to confuse the two as well.

So code up a storm to learn, code up something usable so people will use it and then you can learn from that too.

My own conclusion…

I’m not making an MVP. I’m not going to make a maximum viable product either – rather, the next step in the project is not to make a viable product. The next stage is research and learning. Code is going to be part of that. Dogfooding will be part of it too, because I believe that’s important for learning. I fear thinking in terms of “MVP” would let us lose sight of the why behind this iteration – it is a dangerous abstraction during a period of product definition.

Also, if you’ve gotten this far, you’ll see I’m not creating minimal viable blog posts. Sorry about that.

A Product Journal: The Technology Demo

2015-01-22T00:00:00-06:00

I’m going to try to journal the process of a new product that I’m developing in Mozilla Cloud Services. My previous and first post was Conception.

As I finished my last post I had a product idea built around a strategy (growth through social tools and sharing) and a technology (freezing or copying the markup). But that’s not a concise product definition centered around user value. It’s not even trying. The result is a technology demo, not a product.

In my defense I’m searching for some product, I don’t know what it is, and I don’t know if it exists. I have to push this past a technology demo, but if I have to start with a technology demo then so it goes.

I’ve found a couple specific experiences that help me adapt the product:

I demo the product and I sense an excitement for something I didn’t expect. For example, a view that I thought was just a logical necessity might be what most appeals to someone else. To do this I have to show the tool to people, and it has to include things that I think are somewhat superfluous. And I have to be actively reading the person viewing the demo to sense their excitement.
Remind myself continuously of the strategy. It also helps when I remind other people, even if they don’t need reminding – it centers the discussion and my thinking around the goal. In this case there’s a lot of personal productivity use cases for the technology, and it’s easy to drift in that direction. It’s easy because the technology facilitates those use cases. And while it’s cool to make something widely useful, that won’t make this tool work the way I want as a product, or work for Mozilla. (And because I plan to build this on Mozilla’s dime it better work for Mozilla! But that’s a discussion for another post.)
I’ll poorly paraphrase something I’m sure someone can source in the comments: a product that people love is one that makes those people feel great about themselves. In this case, makes them feel like a journalist and not just a crank, or makes them feel like they are successfully posing as a professional, or makes them feel like what they are doing is appreciated by other people, or makes them feel like an efficient organizer. In the product design you can exult the product, try to impress people, try to attract compliments on your own prowess, but love comes when a person is impressed with themselves when they use your product. This advice helps keep me from valuing cleverness.

A common way to pull people out of technology-focused thinking is to ask “what problem does this solve?” While I appreciate this question more than I used to, it still makes me bristle. Why must everything be focused on problems? Why not opportunities! Why? An answer: problems are cases where a person has already articulated a tension and an openness to resolution. You have a customer in waiting. But must we confine ourselves to the partially formed conventional wisdom that makes something a “problem”? (One fair answer to this question is: yes. I remain open to other answers.) Maybe a more positive alternative to “what problem does this solve?” is “what does this let people do that they couldn’t do before?”

What I’m certain of is that you should constantly remember the people using your tool will care most about their interests, goals, and perspective; and will not care much about the interests, goals, or perspective of the tool maker.

So what should this tool do? If not technology, what defines it? A pithy byline might be share better. I don’t like pithy, but maybe a whole bag of pithy:

Improving on the URL
Own what you share
Share content, not pointers
Share what you see, anything you see
Every share is a message, make it your message
Dammit, why do I feel compelled to noun “share”?
Share the context, the journey, not just the web destination
Own your perspective, don’t give it over to site owners
Know how and when people see what you share
Build better content, even if the publisher doesn’t
Trade in content, not promises for content
Copy/enhance/share

No… quantity doesn’t equal quantity I suppose. Another attempt:

When you share, you are a publisher. Your medium is the IM text input, or the Facebook status update, or the email composition window. It seems casual, it seems pithy, but that individual publishing is what the web is built on. I respect everyone as a publisher, every medium as worthy of improvement, and this project will respect your efforts. We will try to make a tool that can make every instance just a little bit better, simple when all you need is simple, polished if you want. We will defer your decisions because you should decide in context, not make decisions in the order that makes our work easier; we will be transparent to you, your audience, and your source; respect for the reader is part of our brand promise, and that adds to the quality of your shares; we believe content is a message, a relationship between you and your audience, and there is no universally appropriate representation; we believe there is order and structure in information, but only when that information is put to use; we believe our beliefs are always provisional and tomorrow it is our prerogative to rebelieve whatever we want most.

Who is we? Just me. A pretentiously royal we. It can’t stay that way for long though. More on that soon…

[The next post in this series is To MVP Or Not To MVP]