HomeGroup sharing issue on Windows

On both Windows 7 and Windows 8, when you set a folder to be shared with your Homegroup, the status window for the operation pops up in the background, with no obvious indication that anything has happened unless you examine the Windows Explorer icon on the Taskbar.

The first time I tried changing sharing settings on a folder, this confused me. Since there was no obvious feedback, I thought nothing had happened. I tried again, and discovered that there were two windows trying to do the same operation in the background.

This is an odd oversight, and one that was obviously carried over from Windows 7 to Windows 8. Either nobody spotted it, or nobody considered it important enough to fix.

But it is important. Whenever a user performs an action using an interface, that action's consequences should be clear. With something like a light switch, the consequences are obvious. But when the consequences are less tangible, explicit feedback helps make them clear.

Sharing folders with your Homegroup is an action with less tangible consequences. However, those consequences are of great import, since they involve sharing folders across a network. Therefore, the feedback should be made especially visible. The status window for sharing the folders should be brought up in the foreground, and not the background. This is a minor issue, but one I consider important.

UPDATE: After exploring the issue a little further, I found that the status window only shows up occasionally -- a lot of the time, the sharing operation completes with no feedback at all. This is much worse. A feedback window saying "The following items have been shared with your Homegroup" is something I'd consider mandatory, because sharing folders across a network is a security-sensitive action. But as I said earlier, every action you take when using an interface should provide some sort of feedback, in order to make its consequences clear.

Scrolling oddity in Microsoft Word

If you open a web-downloaded document in Microsoft Word 2010 for the first time, it opens in a read-only mode called Protected View. Pressing 'Enable Editing' permanently switches the document to read/write mode.

A web-downloaded document opened in Protected View.

On the other hand, a document created on your PC opens directly into read/write mode from the start.

A document created locally, opened in read/write mode.

There's a subtle inconsistency in scrolling behavior between the two modes. After opening a document in Protected View, you cannot scroll the text using the keyboard (the directional keys, PgUp/PgDn, Home/End) without clicking on it first. (You can't use Tab to shift focus to it either). On the other hand, a document opened in read/write mode can be immediately scrolled using the keyboard.

I'm not sure why this is. Protected View does have heavy restrictions -- you can't print unless you enable editing, for instance, despite printing being an ostensibly read-only action. But I think this is more likely a minor UI programming inconsistency. If that's the case, correcting it shouldn't be too difficult.

I realize this is a minor issue, and one that seems almost frivolous to write about. But as a teaching assistant, I often need to open dozens (if not hundreds) of documents downloaded from the Internet, and at that scale, an issue like this can become noticeable.

Little issues of this sort have an effect on the smoothness, polish, and comfort of a UI. I don't know if Word's development team would consider this an important enough issue to fix. But fixing it would increase the application's usability, if only by a little. Fixing several such issues would increase the usability a lot.

Problems with auto-expand web views

In a previous post (Facebook footer links), I mentioned auto-append views: information views that automatically expand to display additional content when the user reaches the end of the currently-displayed content. More generally, views that append additional content to the content currently displayed, instead of splitting content into multiple pages, have become rather popular recently. (There are both manually-appending and automatically-appending versions of these.) Let us call these append views.

The button for appending additional content to a Yammer news feed.

I consider append views to have the following problems:

• An append view gets bigger and more unwieldy as more content is appended to it. Getting around the content requires a lot of scrolling. (On the other hand, navigating multiple pages of content can be done using clicking. I'd need to do tests to see which method is more efficient.) Furthermore, bigger pages are harder for resource-limited browsers (such as smartphone browsers) to handle -- in my experience, they can slow such browsers down. Google Chrome on my iPhone has occasionally crashed while trying to display large append views.
• Append views often break web history navigation. Since they tend to be presented on a single webpage using HTML5 techniques, instead of on multiple pages, append views possess a specific piece of state information: how much content is currently being displayed. This state information isn't stored as part of a browser's web history, which is why navigating back to one of these views usually requires the user to append the same content again.
  
  On the other hand, multiple pages of content are usually displayed as separate webpages, with separate URLs, so that the browser doesn't need to remember any additional state information in order to accurately return the user to the specific page he was at previously. (Note that I've seen multi-page displays implemented using HTML5 on a single webpage, in which the case the same issue might apply.)
• Because append views are often presented on a single page, it usually isn't possible to provide a link to a specific portion of the content (such as the fifth page of content, for instance). (Note that this can also be a problem for multi-page displays, since their pages are often numbered from the most recent one, so that the page number for a given page of content could change, as could the set of items grouped together on a single page.)

What improvements would I make to append views? I'd find a way to make browsers remember how much content has been loaded into a particular append view, either through session variables or URLs. URLs would also be an easy way for users to create links to specific views of content.