@lindsay.at

Twitter's currently ablaze with talk about the recent change to how @replies are handled on twitter. (Actually, as of this writing, it's ablaze with a shocking number of "RT this if you disagree with Twitter's decision to hide replies to people you don't follow. #fixreplies" messages that cause a massive facepalm.)

While I agree with the change (because for most of my multiple use cases, that's how twitter works best), I feel for the people who didn't use Twitter this way. Their whole way of looking at the social web has been taken away by the elimination of an application preference. That's surely upsetting, and I can't hope to change their minds. But I can try to get them out of their heads and see how the change makes sense for a lot of Twitter scenarios.

I operate a bot, @recomme (which is currently in the shop for maintenance due to another API change that Twitter made with no warning — so my above empathy is real) that feeds on @ replies: send recomme a message, and it tweets back to you, also in the public stream. If you keep your tweet stream private, you must follow @recomme, and it must (auto-)follow you back. The same follow requirements happen if you want to send private messages and receive them back.

This seemed like a reasonable model when I designed it because to me, the sensible way of managing replies was to see only replies to those people you follow and have asserted that you found interesting. @recomme has nearly 4000 followers now. For those people who have kept their settings on receiving replies to people they're not following, that's a lot of eyeballs to reach, especially when anybody can trigger a message from the bot. Fortunately, this has not been noticeably abused by any of the thousands of users. Unfortunately, because of the existence of the all-replies setting, the bot receives nowhere near the number of tweets you would expect from the number of users, I suspect because the social cost of sending tweets to and from the bot are big.

Now, if Twitter stays with hiding replies to people you don't follow, then my vision of an "emergent social network" can happen. People can happily tweet the bot, knowing that people who don't care about music recommendations won't see those tweets or those replies. The people who do care about you and music recommendations do see those tweets, and I think that's a nifty way of opening conversations.

For my own tweets, I struggle with keeping the number of people I follow down, and I have a tough time refusing to read tweets. The "@ replies to people I'm following" setting was an effective filter. Actually, there's a core of twitter users who I know in real life, and I am more keen on seeing all their tweets. (And did so with a secondary account that saw all replies.)

But the real reason why I'm in favor of the recent change is because of new users. Techcrunch actually showed some insight after their typically incendiary headline:

Before tonight I never paid much attention to this train of thought - after all, on Twitter, I can just follow the people I care about and ignore those I don’t. But it’s clear that Twitter is concerned with appealing to a more mainstream audience, and if that takes making a very simple service even more simple, then by golly, that’s what they’re going to do.

Well, yes. Exactly. My pride as an early adopter is far outweighed by the desire to have more close friends and family come to Twitter.

What does a new user see after adding a few friends and "recommended users"? Some tweets, but a lot of decontextualized half-conversations. This is confusing and off-putting. I feel guilty some days when I use Twitter as an open IM/IRC channel, having long threads of conversation. For those who follow all of my tweets, I must seem incredibly boring, geeky, trivial and somewhat profane. That's accurate, but it's not what I like to remind people.

I think that seeing this chatty, focused, decontextualized side of Twitter is not a very gentle introduction for newcomers. It might be useful for comfortable users who have been around for a while but follow dozens of people (or for very prolific users who skim or otherwise filter their tweet stream but don't pay particular attention to any users in particular). But for introducing users to Twitter while fighting concerns that it is "trivial," it's a pretty important step to take.

Some ideas that were thrown at me were improving the experience:

Carr0t

I would prefer it on a per-user basis. So I could say ignore @replies from @stephenfry, but get them from @daagaak.

daagaak

It would be nice for API users, bots, etc to be able to specify if a tweet should act like that. I just dislike the list of discovery.

...in other words, make the control more fine-grained, whether it be push or pull. Well, changing the granularity would be welcome from my selfish point of view. I could zoom in on some users, and not on others. I can see the appeal of the push-control, too. I would have welcomed making @recomme more private, if that had been an option.

But the truth is, that's all too fiddly. It makes a degree of sense to a "power user" like me, but from a user standpoint, it's a disaster. Too many things to control. The point of the change was to simplify a hard to understand option, something that I stand behind on principle.

On the other hand, Anne said, "Never take options away from a user." Those are also wise words. My gut instinct to make as many people happy as possible would be to grandfather in the feature: keep the option for those who have changed from the default, make it disappear for all others. This creates two tiers of users, though, which is untenable in the long term, especially from the social aspect: these exceptional users have a view on Twitter that is fundamentally different from others, and are likely to use it differently. As such, I think the feature should be phased out. Leave it to clients to support an expanded view of the greater twitterverse.

There's a Twitter truism that's been floating around: "Anyone who tells you how Twitter should be used is wrong." I've tried not to fall afoul of that here, but it's a fine line.

I'm not a programmer. I don't harbor dreams of writing elaborate code that gets lots of users and has lots of programmers follow my lead. But once I get into it, I enjoy hacking on code, and am happiest to have just a few lines of minimal and/or clever code that a few other people with odd tastes might also enjoy making use of. I like to share.

I've been thinking a lot about distributed revision control and online code hosting lately. I've stirred up a few conversations on twitter because of these thoughts, and wanted to lay them out here.

I tried with Git. And I got far enough with it to get into trouble. I eventually made a mess of a few commits on a public (SVN) repository. Since I couldn't make distributed revision control work with subversion, then I ended up learning subversion better (and rsyncing between my private, local branch and the mainline). From the start, I found git to be too far from my own mental model, and too optimized for situations I didn't value (huge code bases, distributed teams of mergers, fast performance and in-place context switching). So I didn't try very hard. That's fine. There were other choices in distributed revision control.

I liked Bazaar from the start, largely on its stated values (easy model, one repo is one directory, concentrate on getting it right before making it fast), and that it got me up and running quickly. It wasn't only from the out-of-box experience, but the excellent documentation on different prototypical users and their workflows, and the fact that there was an easy path to push repositories to a remote server using only sftp .

When I was looking at these solutions, I set Mercurial aside, because it didn't seem to have a lot mindshare at the time, and I had difficulty installing it on the Mac the first time. (Actually, I had problems recently, until I realized that using the Makefile was far less effective than using my oft-incanted 'python setup.py install'.)

It's a bit over a year and a half later, and some of the sheen has definitely gone off bzr for me. There are some little annoyances that have built up over time:

• The admirable striving towards "getting it right" has resulted in many updates to the repository format since I got started, and countless updates to the mainline program. This commitment to keeping the project up to date is admirable, but it's annoying to chase.
• My dependency on the rspush command (I like to have a working copy of my most important repositories on remote machines, and not have to rely on installing bazaar if something goes horrifically wrong) means that I must always install the BzrTools plugin, which multiplies the annoyance of the development churn.
• bzr-svn was extremely unsuccessful for me.

I could deal with these small issues easily, but the big issue is becoming hard to ignore: if I want to share my repositories with other people, then I don't have a clear way of doing it.

Yes, I know about Launchpad. I've even hosted a now-abandoned project on it. It's an impressive bit of engineering and a wonderful, completely free service. There are numerous interesting projects with a home there . I just don't think any of my near-future projects could have a home there.

As a dilettantish coder , I am drawn to the sorts of odd little projects that one sees on Github. I can easily bookmark a project for later inspection, and do so often. Github's prolific social model clearly works. It knows that its users are developers, and makes every part of its interface geared towards that. I feel comfortable enough with git that I might branch, modify, and push back existing code, but I don't feel comfortable using it to organize a project of my own doing.

Launchpad's hosting, by contrast, feels "heavy." In fact, it feels like a SourceForge clone, where it hides the code away, and concentrates on end users. That's great for users, and sounds very appropriate to the user-centric focus Canonical has. But I don't need a bug reporter and project planning and translations and a knowledge base. I want programmers to see my code and to get my code if they want. I want to provide some context in the form of a README. That's more or less all I need to publish.

On Launchpad, giving a context involves writing text in a web form that's half the size of the form that you are given for telling people how to report bugs. Nothing is integrated with the excellent revision control system other than the code itself — and the code is consistently four (non-obvious) clicks away from the project home page.

I have devised a crude way of making a permanent note of a project's code I want to remember, but it's a multi-step process (involving "subscribing" to a code repository, but disabling all email notices of changes) that I keep forgetting how to do. I'm not saying Launchpad isn't usable: it's not easily usable by me, who likes using the developer-as-user-centric Github model.

(Google Code, as an aside, is nice. It's unobtrusive interface has a nice set of features, and they get out of your way when they're not needed. It's not instant to – for example – assess how fresh a project is from the date of its last commit, but that information is a couple consistent clicks away. I just don't want to initiate a project using subversion, knowing that, given my history, it will reach some state of abandonment eventually: if I'm the only developer, then the SVN repository is essentially locked away in an immutable state forever. I'd rather let people discover my code three years down the line and branch freely.)

So, what am I thinking about now? Despite some encouraging words I heard from a local developer who's on the LP team, I'm very dubious about the prospect of Launchpad bending to my will. It would involve de-emphasizing the work of half a dozen teams in the web interface, all in the interest of Making Things Nicer for Adam. However, building something new up from something minimal might work well. It wouldn't be that hard to expand Loggerhead, the core Bazaar repository-view web app, to include basic social web features. It's a foolish thought for me to have at this time (when I need to put all my available energy into the thesis).

On the other hand, Bitbucket looks like a pretty reasonable Github clone, and from my experience, hg's model is not too far from bzr's. Right now, barring any further developments, I'm considering publishing future projects there. Yes, it would involve changing to hg (Snej's Murky makes that a bit more inviting.) On one level, that's mad, to change my revision control system on account of an social web application (that's an unapologetic clone of a different, wildly successful service). But that's what's important to me right now: if I want to share with the world, I want enough people to see my code and take it home with them. I want it to be easy for me to manage changes and evolve the code for as long as it engages me, then set it free.

Well, I think I've said some fairly dismissive things about just about anyone's favorite tool and/or service. I'm opinionated, but I'm ready to learn from those who like to inform and engage politely and productively. I'm not, however, interested in zealots.
So. Thoughts?

Would you pay $849 for a new MacBook? - Apple 2.0:

According to AppleInsider's Kasper Jade, Apple sees the cuts — which could come in the next month or two — as an 'interim solution' to the growing popularity of netbooks, those sub-compact laptops that Steve Jobs once dismissed as 'a piece of junk' but which are flying off the shelves at $299 to $349 apiece.

Another round of wishful thinking via rumour, but I just wanted to point out that what's key with watching Apple here is not the bottom price points, but the interlocking matrix of price points. Over the years, led by their iPod business, Apple has mastered the art of the upsell through models with additional features. I think the turning point was the introduction of the iPod mini, at $249. For 'just' $50 more, you could get a full-sized iPod with nearly four times the capacity.

Take a look at the Mac portable and desktop, consumer and professional lines, and see that the jump from one product to the next is about the same as the jump between models within a product line. Really, spend some time at store.apple.com, and see that the price matrix is just as precise and artful as the company's engineering. The question is not "how low can Apple go?" but rather, "what shift in the prices of existing products will suggest more models in another product down the line where an upsell to the current cheapest product is an easy jump to make?" (Easy, eh?)

So let's speculate irresponsibly. If the current white MacBook model goes down to $849 (which is already a leap because Apple doesn't cut prices lightly, as they know it's hard to turn back), as the linked article proposes, then it would support netbooks at $749 and $649. Or maybe "MacBook Minis" at $599, $699, and $799. Adding one product line doesn't get you close to the mythical $349 that people are wishing for.

Wait, should that be "MacBooks Mini"?