13Mar / 2008

cow-orking

After an achy day in a coffee shop chair yesterday I spent some time last night looking up co-working again. Nothing new has happened on Co-Working Boston page since I was last there. However the CSMonitor recently ran an article covering Betahouse, a local co-working facility, previous covered in this boston.com article.

Lazy Cow (…) by law_keven. License:

After I first posted my name on the Co-working Boston page I got a message from someone near Long Island looking to open up their own co-working facility. The issue in setting a new place up seemed to be finding the price to set. She wondered if I had a price in mind and since I’d been thinking about this already I sent her my formula for deciding what to spend.

I’m a bit of a details dork and this was formula to calculate my average commute costs when I used to drive to work everyday.

Distance: ~ 30 miles from Cambridge to Westford

Cost: ~ $0.505 per mile according to the Federal reimbursement numbers (which likely don’t take into account recent gas prices)

60 miles round trip / day * $0.505 = $30.30 / day

Working Time: 1777 average hours per year worked according to wikipedia which is 222 working (8 hour) days / year. Really you want number of days driven, not number of days 8 hours were worked but the total usually comes out to be less than the real value and therefore we end up with a conservative estimate.

$30.30 / day * 222 avg working days per year = $6727 / year ( or $561 / month )

Even if I through in the monthly T pass of $59 / month I now get and the fact that I still own the car ( payment + insurance + tickets and taxes) there is a considerable amount of money left which could go towards sharing a nice office space. However since I’m pretty cheap I’d probably opt for the $200 / month deal and be a part timer, after all the coffee shops do have their charm as well.

Title coming from the excellent cow-orker slang term.

Hello there planet mozilla

Permalink 8 Comments

01Nov / 2007

Network Resume Dance

I learned this little dance while Network Manager was having a problem with sleep and resume. Bringing my laptop out of sleep always had problems getting networking again. Network Manager would die upon resume so this is how I would get my wireless card (iwl3945) to return after resuming from sleep. I’m looking forward to not running this all the time…

[clarkbw@localhost ~]$ sudo /etc/init.d/NetworkManager restart

Stopping NetworkManager daemon:                            [FAILED]

Setting network parameters...

Starting NetworkManager daemon:                            [  OK  ]

[clarkbw@localhost ~]$ sudo /etc/init.d/NetworkManager stop

Stopping NetworkManager daemon:                            [  OK  ]

Now wait about 10 seconds…

[clarkbw@localhost ~]$ sudo /etc/init.d/NetworkManager start

Setting network parameters...

Starting NetworkManager daemon:                            [  OK  ]

[clarkbw@localhost ~]$

Permalink 5 Comments

26Oct / 2007

Managing your Wireless Networks

Last post about Network Manager for a little while, I swear…

The current state of Network Manager doesn’t allow you to easily manage the wireless access points that you connect to and how it connects to them. NM also doesn’t allow you to easily stop it from auto-switching from wireless to wired networks when you connect a wired cable. We explicitly avoided a “manager” style interface for the smother and simpler auto connection interactions we currently have. However we haven’t been allowing people to control NM in certain normal cases where the auto connection system breaks.

Window Shopping

The use case we’re failing at right now in regards to managing your wireless networks is what I like to call Window Shopping or “Just looking”. At a conference or a coffee shop it’s very normal to attempt to connect to a number of networks, often to see if they are working and fast or free! After connecting, or not connecting, to these networks it doesn’t take long to realize that you’ve connected to something that isn’t going to work. However Network Manager doesn’t have the same realization as you, it remembers that network and will try to connect to it again next time if there isn’t a MRU network in range.

Since this case presents mostly an “inline” mistake to the way NM is choosing networks it seems to make the most sense to employ an inline interaction to handle those mistakes. Inline, in this sense, meaning that you don’t want to require people to manage the networks outside of when NM makes a mistake and chooses the wrong one; like only having a right click menu to open the network preferences dialog. Here’s some mockups to explain more.

Most people will see this when they connect to a wired network.

People who turned off auto-wired connecting would see this notification.

People who turned off auto-connect on a particular wireless, like rh-wireless, would see this notification.

Most people would see this notification as they auto connect to their particular wireless network. The buttons look really bad! Please leave comments for ideas on better ways to handle this.

Update: Just to note that the default behavior of Network Manager isn’t changing with these notifications, it is still going to behave in the same automatic way. However the new notifications add support for changing it’s automatic behavior.

Network Preferences…

This is supposed to open up a network preferences dialog. Most likely one tab for wired and one tab for wireless, the wireless tab allowing you to edit networks you use and possibly properties of the wireless behavior. Dan asked for a wired tab, I’m not sure what the properties will be on that dialog… they are likely to be scary enough to make me puke.

Don’t auto-connect again / Always auto-connect

So this isn’t a great way to phrase things. There are two scenarios, you’ve auto-connected to a wireless network you connected to once but didn’t mean to OR you’ve connected to a wireless network manually that you told NM never to auto-connect to. Essentially what I wanted to say for scenario one was: “Don’t automatically connect to this network again” – but that’s a large button. And for scenario two I wanted to say: “Despite how I changed this wireless to manual mode I want you to always auto-connect to it from now on”.

I should mention the wired is a slightly different case from the wireless. It’s more like saying, “Don’t auto-switch me to wired from wireless when I connect the cable”.

Permalink 22 Comments

17Oct / 2007

Scanning for Feedback

Yesterday morning on the bus I was talking to Dan and asked if Network Manager could export a signal when it is actively searching for networks. As I mentioned in the previous post and many people pointed out in the comments that we need some feedback when the wireless card is actively looking for new networks. The situation where this happens most often is a laptop resuming from a suspend. When the laptop wakes Network Manager clears it’s AP list and starts scanning channels filling the fresh list. As it finds new networks and fills the AP list NM doesn’t tell the UI (nm-applet) that it is actively searching for new networks. Often the only feedback that the user receives is when NM finds a network it knows and begins to connect to it.

To improve this scenario we need some real user feedback during the scan process. I don’t think using an animated icon to show that NM is scanning is necessary, I think it might actually make things a little too busy.

Currently NM will display this “network disconnected” icon even while the wireless is actively scanning.

network disconnected

Instead lets try to use a simple static icon that indicates wireless is active and working. (something like this, my icons are not to be trusted…)

wireless actively searching

In addition to the icon, it might be good to display some kind of message in the applet menu stating “Scanning for New Networks”

Ideas? Leave them in the comments!

Permalink 17 Comments

16Oct / 2007

Refresh in reactive displays

In the web world every browser needs a refresh button because the main protocol (http) doesn’t allow for the web browser client to know if there were changes made on the remote end. Lots of MacGyver like fixes using AJAX are built to accommodate the fact that the web is stateless and yet we use it for almost everything even though it’s probably not the best protocol out there, just the most pervasive. The lack of state change events coming from the remote http server makes the system non-reactive and the user interface becomes a static copy of what we asked the server for, thus we have to refresh and poll the server for changes.

When the system behind the user interfaces are reactive the user interface should be a dynamic representation of the system and thus a refresh/reload system doesn’t actually make much sense, and in fact it can be a bad thing. Take the mockup below as an example, it’s the NetworkManager applet with a refresh button packed tightly into the menu. (this is not a good thing)

bad idea

A refresh button like this is tempting for people to add to the interface because it might help work around some of the networking bugs current Linux systems have. However a button like this is not helpful for everyone, it actually erodes away at the experience of NetworkManager (NM).

Reactive Back end

Network Manager is controlling the wireless card in your computer to scan for new networks when most appropriate, finding new networks as they become available. Both types of scanning, passively and actively, are governed by Network Manager in order to be friendly to the access points and wireless networks around you as well as give you the most up to date list of available networks. So NM effectively acts as the proxy to the polling system that happens in your wireless card, delivering a stateful display.

Because NM is providing this kind of reactive back end to wireless networking our display interface (nm-applet) can be fairly simple since everything is just a dynamic representation of what’s out there. Assuming NM is working as it should be the list of networks shown in the applet is always going to be the full list of available networks. Using a refresh button on this kind of dynamic display starts to change that view.

Putting You to work

Since our interface is assuming that NM is always presenting us with all the available networks there is no need for a refresh button. It’s actually just making you work a little more when that work should be inside of NM itself. The one-two step interaction of clicking on the applet to view the wireless networks and then choosing from the available networks becomes a two-three(-repeat) step system where you have to open the applet and click refresh (because you can’t be certain anymore that the applet is showing the correct list), then opening the applet again to see what changes.

Why is it a bad thing to have a refresh button in a reactive display? Because it creates an unneeded inconsistency in the interface. When you look at the mockup above you can’t know if those networks are all that are available… until you hit the refresh button. The refresh button creates an inconsistency by making you think there’s extra work to be done before you can assume there are no other wireless networks. Without the refresh button you have to assume there are no more networks available, of course there’s no way of knowing if NM is looking for more networks or not (more on that below).

Where things go wrong…

Most of the issues in this area of wireless networking on Linux come from systems not telling NM to suspend, sadly your distro is somewhat responsible for making this happen. There are lots of other possible problems through the whole stack from wireless tools to driver support that can make things not work well. But in the end the fixes need to go down into the networking stack to instead of up in the user interface.

Aren’t we still missing something?

So where did we go wrong? Feedback. (often the right answer in interaction design)

The Network Manager applet does lack in user visible feedback during an active scan. When you don’t have a network, either after booting up or resuming, you don’t know if network manager is scanning for new networks. I’m usually left wondering what it’s doing until it connects to something. It would make sense to have some kind of feedback in the applet that indicates it’s currently scanning for wireless networks while you don’t have one (scanning while you are connected to a network isn’t that interesting).

Permalink 19 Comments

06Jul / 2005

Rictus

Today’s word is rictus, meaning a gaping grin or grimace. Probably relating to me miss-spelling yesterdays word in the title or possibly other stupid things I did.

Notifications

Rodrigo makes a bunch of good points in his entry.

The dialogs that Gaim and Evo use are ridiculous and disturbing but just using notification bubbles doesn’t solve that. In my opinion Gaim or Evolution should never tell you, in a dialog or bubble, that it has gone offline or online. The only exception to that is when you actively try to do something with those programs. In Evolution if you try to check your mail or send a message, then it should make you aware that you’re offline and that won’t happen; a simliar for Gaim as well. So I agree that notifications of new mail are low priority and shouldn’t steal focus, but sometimes the dialogs are helpful like in my next example.

For notification history. It seems like there are two problems, one is that we want a way to look at notification history, and two is that an alarm like that shouldn’t go away completely until you’ve dealt with it. For the first part I suggested that something, like the notification area applet catch all notifications and save them. I guess the libnotify daemon process does this, so it should probably be integrated to display those from the capplet. The second one is just a matter of the application being smarter about the type of notification it’s showing. Perhaps evolution alarms should start off as a bubble up item when they first appear and when you only have 15min before they appointment they appear as dialogs. It just seems as though we don’t need to make a one or the other preference, but use the bubbles as low priority and when you’re about to miss your meeting use the dialogs as slightly higher priority.

As far as the implementation goes it doesn’t really matter to me at all what is used. I said the same thing to the Desktop team. I think we should be trying to use the libnotify work as much as possible and work with those guys because they’ve gotten a lot of good work done. However, I get the luxury of demanding the right type of notifications for people using the desktop before the implementations available.

If libnotify is the best thing so far that’s fine with me, they might just have to deal with me whining all the time until we figure out a solution.

Evince

Jonathan already talked about this, but it’s too sweet to not show it off. Evince has great text selection support, according to krh it’s the best text selection out there, it even supports themed selection colors!! And I guess Evince has jumped on the bus like everyone else. This opens Evince up to remote control for presentations and allows you to query evince for what documents the person currently has open.

Threats

Ok, so David Z didn’t actually threaten to punch me in the face, but he had that CRAZY look in his eye.

NetworkManager

I sat down with Dan and David not too long ago and worked out some design goals for NetworkManager. We basically wrote down some experiences we want the person using NetworkManager to have. Also we started on the Network Administrators experience admining and setting up NM. I’ll be posting that stuff soon and we’ll probably get getting a new website to reflect all the new information.

Permalink Leave a comment

12May / 2005