LoFi-Group:ThePenIsMightier

From CS160 User Interfaces Fa06

Group Contributions

• Charles Lee - Charles authored the Introduction and Mission Statement, Procedure, Incident Log with Ratings, and Testing Script; he co-authored the Tasks, Environment, Summary of Results, and Test Measures. He also organized and greatly contributed to the notes and interface improvements/ratings during the interviews and incident log; contributed to the Prototype and Discussion sections, and played the roles of Greeter, Facilitator, and Observer/Note-Taker for the interviews.
  
• Vahe Oughourlan - Vahe authored the Participants section of this assignment, and contributed to the Environment and Testing Method. He also played a large role in the creation of the lo-fi prototype elements, such as the desktop, as well as observing, aiding in the role of Computer during the interviews, and helping capture the interviews on digital camera.
  
• Tom McClure - Tom was the primary author of the Prototype section of this assignment, and played a large role in the creation of the paper prototypes, such as the blog post wizard screens. He also played a large role in the design of the interface, as well as playing the role of Computer during the interviews, helping capture the interviews on digital camera, and processing the images of the paper prototypes.
  
• Tony Lai - Tony contributed to the Results and Tasks sections of this assignments, as well as observing and taking notes during the interviews. He also created the consent forms, which can be seen in the Appendix section. He also contributed to the lo-fi paper prototype - namely, the settings screens and the main screens.
  

Introduction and Mission Statement

We are creating an interface for the Anoto Digital Pen, with the intention of allowing bloggers and journal-keepers to create an electronic record of their writings, no matter where they are, while using the easy and familiar interface of pen on paper. We want to allow bloggers and journal-keepers to create posts as soon as they see something inspiring, without needing to wait for their next free chunk of time at an internet-ready computer, and without carrying around an unwieldy computer.

Interview Roles

• Charles Lee - Charles acted as the Greeter, Facilitator, and Observer for all the interviews. Also recorded improvements for the interface in the interview notes.
  
• Vahe Oughourlian - For the first two interviews (with Curly and Moe), Vahe played the role as one of the observers. He was also responsible for the video recording equipment during those interviews. For the last interview with Larry, he played the role of Computer.
  
• Tom McClure - For the first two interviews (with Curly and Moe), Tom played the role of the computer. He was also responsible for the video recording equipment during the last interview with Larry.
  
• Tony Lai - Tony played observer for all the interviews, taking detailed notes for the issues that were brought up during the interview process.
  

Prototype

Select Pages Dialog (Publish Wizard Step 1). Note the use of direct manipulation in selecting a page range.

Select Action Dialog (Publish Wizard Step 2)

Post Blog Dialog (Publish Wizard Step 3)

The group met and discussed the solution sketch from the previous project, and we were able to use many elements of this storyboard as a starting point for our design. We reviewed the tasks that were not yet handled by the existing plans and expanded the scope of the application to handle these tasks. Whiteboard sketches proved to be the ideal media for exchanging ideas about what screens/dialogs were needed and what elements should be on each screen and where.

The fluid affordances of dry-erase markers and whiteboard came in very handy at this stage, and gave the team the opportunity to make a couple quick iterations with corrections and improvements before committing the design to paper, much like how we make quicker iterations on paper than with a completed application.

We chose a "wizard" based design, since we recognized that a significant portion of our target users might not be very comfortable with desktop applications, other than their web browser. The "wizard" paradigm is helpful because it breaks the tasks into steps. In consideration of the ability of humans to focus on only a few things at a time (7 +/-2), we tried to avoid asking too much of the user at any given step. Otherwise, the user's locus of attention would not be able to contain the cause and effect between their actions, then possibly become confused and dissatisfied with the process, at worst abandoning using the program. As well, the wizard paradigm is a loose natural mapping with a book, flipping to subsequent pages by the bottom left and bottom right corners.

Another benefit of the "wizard" paradigm is the availability of "back" and "next" buttons at a standard fixed position (the lower right corner of the dialog) in each intermediate stage. Even users not familiar with this convention quickly learned the interaction and internalized it. This is not fully implemented direct manipulation, but allows the user to more comfortably navigate the proccess.

The Library

We anticipated that users of our system would need a tool for navigating all the content that had ever been imported into the system. This provides access to the pages saved in previous docks. We experimented with a few different layouts and settled on using the metaphor of a "Library." This term seemed more friendly and appropriate than the alternatives "Archive" and "Dock History." The Library quickly became the central "home" of the application.

Docking the pen (or clicking "import" from the library) triggers this dialog

On the left hand side of the Library we employed a list control (similar to the one found in the Windows file system browser) where each item in the list corresponds to a set of pages -- or "BlogPad Document" -- imported in a single dock. In addition to a descriptive name for the document, the date of import and the number of pages is listed. Since the list control allows you to sort by any heading, we predict that this will prove adequate for most situations where the user is trying to locate a particular document. The default sort is by import date, with most recent imports listed first.

Selecting an item in the Library list loads the actual content of the pages into the preview pane on the right. The preview pane allows easy navigation through each page of the blogpad document and provides additional details about the document (date of first stroke, date of final stroke).

The Library also provides an alternate launch point for the publishing wizard, although it is expected that this will typically be triggered directly by docking the pen.

Additional Elements

Additional elements of the paper interface appear below. Two extra dialogs were created on the fly after user sessions when our users suggested improvements to the interface. Post-its were handy for this quick design improvement.

This "BlogPad Publishing Settings" dialog also appears (with back/next buttons) the first time a user tries to publish to their blog, between steps 2 and 3 of the publish wizard.

This standard "Select Filename" dialog appears when saving a page to an image file.

This "Dummy" Browser Window launched with LiveJournal showing the posted blog entry

Method

Participants

• Larry - The Mac Guy

Larry is a Computer Science major here at Berkeley. He is an undergraduate, and primarily a Macintosh user, using the OS X platform. He blogs very rarely, if at all, and he does so on multiple blog sites, not just one site in particular. He was chosen as a control of sorts in that he is not a Windows user, and our interface is Windows-based, using Windows conventions, thus we wanted someone who is familiar with graphical user interfaces but not familiar with Windows in particular.

• Curly - The Designer

Curly is a graduate from UC Berkeley who left the university about five years ago and currently works in a computer-science related field. Curly is very advanced user, comfortable with both Windows and Unix. Curly was chosen for his discerning eye towards detail, design, and usability, since he works in the field and has real-world experience regarding such issues. Also, Curly is not a blogger, and thus can provide an unbiased view towards the user interface design, in the sense that he need not view the software as blogging software per se, but as some piece of software in general.

• Moe - The Simple User

Moe is an EECS major at Berkeley who is just starting into his technical and programming classes. Like a number of EECS and CS students, he does not have any prior experience with programming languages or the in-depth workings of computer software; he is simply a computer user. Therefore, we can treat him as a representative of more general, less technical computer users that may use our software, and not be concerned about the more technical bias that either Larry or Curly may introduce.

Environment

The graphical user interface test was conducted in the CSUA Lounge in Soda Hall, which is a well-lit, spacious, and quiet area in which to conduct these tests comfortably. The "desktop" environment was a large rectangular table, where the user sat on one of the long edges, while the "computer" was stationed opposite him. The note-taking member was stationed at one of the short ends of the table, and the greeter was stationed at the other end. The camera operator sat to the left of the user some distance away so as not to interfere, but also be able to capture the interaction on video.

A single sheet was used as the "desktop" display similar to the Windows desktop, complete with a "My Computer" icon and Start Menu (click here to see the desktop). On top of this "desktop" sheet were placed all of the "windows" used in our experiment (see the Appendix or Prototype for more examples). A folder was used as a barrier between the "computer" and the user so as to hide elements of the interface from the users, so they would not attempt to "chase down" elements they may not have discovered in using the interface.

Tasks

Easy Task

The easy task we chose was for a user to save a blog posting to his local computer. We chose this as the easy task because there are the fewest steps involved, all of them requiring very little reaction besides naming their post and pressing "next".

Steps

1. Dock pen

2. Window popped out, asking if user wants to post to blog. Type in name for blog, click "No Thanks".

3. Confirmation for blog saved appears, done.

Medium Task

The medium task we chose was for a user to save and upload his writing to a blog as one post. This task requires a few more steps than the easy task - after saving and filing his post, he must name and title his blog posting, which may have different titles, although the existing title would be available by default.

Steps

1. Double click "BlogPad"

2. BlogPad library appears. Click on name of blog user desire to post. Click "publish/export"

3. Posting interface appears. Default option for entry start and end mark was set on "snap to boundary", so click next

4. Since it is the user's first post, a one-time blog account configuration window appears. User inputs information, then clicks ok

5. Window for blog posting information appears. User input information and, click next.

6. Browser with user's blog on blog site appears with the user's new post, as confirmation of the posting (if the user has selected that option).

Hard Task

The hard task we chose was for a user to save and upload his writing to a blog as multiple posts. This task requires the user to fully utilize the "Mark entry start/end" tool in the posting interface. Its purpose is to allow the user to upload multiple days of blog posts in one sync-up operation.

Steps

1. Double click "BlogPad"

2. BlogPad library appears. Click on name of blog user desire to post. Click "publish/export"

3. Posting interface appears. Click on "Mark entry start", then click on corresponding starting point of blog on page previews at the left.

4. Click on "Mark entry end", then click on corresponding ending point of blog on page previews at the left.

5. Click "next"

6. Since a blog account has already been created, the blog account configuration window does not appear again. The window for blog posting information appears. User inputs post title and date, then clicks next.

7. Browser with user's blog on blog site appears, user closes browser

8. BlogPad library remains. Click on name of blog user chose for previous post. Click "publish/export"

9. Posting interface appears. Click on "Mark entry start", then click on corresponding starting point of blog on page previews at the left.

10. Click on "Mark entry end", then click on corresponding ending point of blog on page previews at the left.

11. Click "next"

12. The window for blog posting information appears. User inputs post title and date, then clicks next.

13. Browser with user's blog on blog site appears, done.

Procedure

• First, introduce the system to the user to give the user background on the situation.
• Next, demo opening and closing the Blogpad program to familiarize the user with using a paper interactive interface instead of a normal computer desktop interface.
• Then, demo writing and docking the pen, to familiarize the user with the concept of docking.
• Finally, present the user with one task at a time, and observe the specimen in his new environment!
• Before dismissing the user, ask him about any confusing parts, great features, or any other tasks he would like the application to be able to do.

Script:

Introduction:

Hello, thanks for agreeing to test our design. We will be watching you try to do three tasks with our application, so that we can evaluate its clarity and usability. As part of our design process, we will be using paper prototypes so that we can quickly make changes to our interface as we learn what it is lacking, before it is actually implemented.

(Mission Statement) We are creating an interface for the Anoto Digital Pen, with the intention of allowing bloggers and journal-keepers to create an electronic record of their writings, no matter where they are, while using the easy and familiar interface of pen on paper. We want to allow bloggers and journal-keepers to create posts as soon as they see something inspiring, without needing to wait for their next free chunk of time at an internet-ready computer, and without carrying around an unwieldy computer.

(Background) The three tasks are going to be to save a piece of writing to your computer, to post a piece of writing as a blog post, and to post a piece of writing as multiple blog posts, in the case that you have written several days worth of blog posts and are now uploading all of them at once.

Initial Demo:

Here we have the paper prototype for our interface. Use this as you would a normal computer's desktop. The model is entirely interactive, and you can click with your fingers. This is how we open our program, Blogpad, and if we hit the 'X', the program closes.

Further Instructions:

(Task 1) Now, let's try your first task of saving a piece of writing to your computer. Please do talk your way through your thoughts as you do so. Here's the pen, go ahead and dock it.

(Task 2) Good job, let's try the next task of automatically posting your writing to your blog.

(Task 3) Great, now let's do the final task: upload the writing in the pen as multiple, separate blog entries, say, two, for example. Note that you will not have to setup your blog login/password information again.

(Follow-up) Thanks for helping us out. Are there any parts that you found confusing or unclear, any parts you thought were absolutely great, or perhaps any features you think would be useful?

(Closing) Alright, thanks again for your time.

Incident Log

• User 1 had trouble figuring out the posting interface (posting interface is where the user select what to post) - two failed click attempts, half minute of confusion. "Major usability problem: important to fix", User confusion makes it likely for users to just abandon the software.
• User 1 spoke what he wanted to do (mark start and end of post), but did not find the way to do it as intuitive.
• Improvement: add a default folder name for local copy for the upload to blog screen. "Minor usability problem", slightly quicker process available for the user
• Improvement: make a paper prototype browser window, "Cosmetic problem" - just looks nicer.
• Improvement: change “blog” to “pages” in posting interface, "Cosmetic problem" - typo/writo
• User 1 expected to see confirmation for files being saved immediately after pen was docked, "Minor usability problem" - confirmations are good for the user.
• User 1 would like a ‘delete’ button for library entries, "I don’t agree this is a usability problem." - the keyboard's delete button works just fine.
• Have ‘jump to blog’ button clickable on most pages, "Minor usability problem" - convenient for the user.
  

• User 2 attempted to click on the pages to select an area, then tried to drag and drop the buttons. This is likely due to a "pushable" paper button not looking different from a paper icon. "Cosmetic problem" - likely due to the paper prototype
• User 2 attempted to click on the pages to select an area, then tried to drag and drop the buttons. This is likely due to a "pushable" paper button not looking different from a paper icon. "Cosmetic problem" - likely due to the paper prototype
• Improvement: move the sidebar to the left side of the screen, so that users would read the "Start selection" and "End selection" buttons first. "Major usability problem: important to fix" - less confusion for users, who were interacting with the left side of the screen before the right side, even though they needed buttons on the right side.
• User 2 wanted a scratch tool so he can black out portions of what he wrote, "Minor usability problem" - added bonus features.
• Improvement: have a checkbox directly above the final "Post to blog" button that allows the user to select whether he wants his posting to pop up in a browser or not. Major usability problem: important to fix" - confusion for user; must make the cause of this consequence more obvious and controllable.
• User 2 wanted to have an easier way to post multiple blogs, "Minor usability problem" - from our admittedly limited sampling, few users have multiple blog accounts. We can choose to support this, or not.
  
• User 2 wanted to manage postings offline, and then go online and post multiple entries at once. "Major usability problem: important to fix" - convenient to the user, and not needing connectivity is one of the affordances of the pen interface, so we should try to keep this affordance.
• User 2 wanted tool for blacking out text, and changing text color in posting interface. "Minor usability problem" - People can just cross things out with their pens.

• User 3 mentioned that fewer steps would be better for this process, "Minor usability problem" - We will compress things into as few steps comfortable to users.
• Improvement: eliminate the "Snap to boundary" buttons. Replacement functionality provided by location where start/end markers were placed: in between pages automatically snaps to boundary, and middle of pages cuts the image. "Major usability problem: important to fix", this modal interface has troubled all of our users. Replacing it with a natural mapping
• Improvement: Change Publish/Export button into two different buttons - "Major usability problem: important to fix", although currently we have 1 button for saving externally and 1 button for saving internally, publishing to blog and exporting are sufficiently different actions so that it would be clearer to have separate buttons.

Test Measures

In the interviews conducted the group watched for several behaviors in the test subjects that would indicate either success or failure with the design of the current iteration of the interface. We knew we could not expect to get useful data by timing the reactions of the users, since much of the time, the user was waiting for the reaction of the computer, as well as attempting to decipher the lo-fi interface. Therefore, we sought to observe significant pauses in the users' interactions with the interface, as well as any hesitation that might indicate that the reaction of the interface was unclear. Also, if the user was forced to ask a question or seemed so unsure of the interface as to need to ask a question, we saw this as a major issue.

We also looked for certain reactions once the interface became somewhat familiar to them after the "easy" task. Especially important was the tendency for users to simply click through dialog boxes without reading them, as many users are wont to do. We looked for reactions that we didn't expect the user to do, but thought made sense, which happened consistently on one screen. One of the most obvious and most telling reactions we looked for was surprise, either in a positive way (where they liked how the design worked) or in a negative way (where they did not expect such a reaction, as with the browser pop-up for Larry).

Results

The result from the user study suggested that our design in general is intuitive enough to be understood by most users, but it was also clear that we need to re-think our process on handling multiple postings.

Task 1:

Of the three users for our study, they were all able to perform task 1 without much difficulty. One interesting suggestion that was raised by one of the users was that we should have a screen that prompts the user to save posts to a local directory, immediately after docking of the pen. However, our group decided that there is no need to change our current design as the other two users had no dissatisfaction about this particular part of our interface.

Task 2

For this task, the users had little trouble completing the task, but all three users were briefly confused by our interface for choosing what to post to the web blog (the "posting interface"), especially on how to mark the beginning and the end of the blog-to-post. The way the user was supposed to mark the beginning and end of a blog was to click on the "Mark entry start" button, choose where the blog starts by clicking the corresponding area at the page previews on the left, and repeat the same procedures for choosing where to end the blog. Yet, instead, one user intended to select pages to post by highlighting all the pages (via key command ctrl-A), and the other by reversing the "Mark entry start"-click on preview procedure. One interesting thing about this task was that one of the users was able to complete this task without using the "Mark entry start/end" tool, as he clicked the "next" button immediately.

In terms of functionality, one user suggested to add in a scratch tool so users can blackout the unwanted portion of the blog. Also, another user mentioned that the steps required to complete this task was too many.

Task 3

This was the hardest task for the users. Like the previous task, users also had problems with marking the beginning and end of the blog-to-post in the posting interface. Yet, after posting the first of two blogs that they were asked to post, users had no problem posting the second blog. During this task, a couple complaints about the interface came up. One of them was that it took the exact same 3 procedures to post the 1st and 2nd entry, which the user felt it was repetitive and unnecessary. Another complaint was that the user thought having a "blog has been posted" confirmation pop up is better than having a pop up browser that shows the actual blog online after every entry.

General suggestions for the application

- support posting blogs to multiple blog sites

- create "jump to blog site" button so users can go to blog site any time

- create wizard for initial settings

- confirmation message after pages were saved locally

Discussion

The testing experience and interview process, as we expected, brought out the failures of several elements of our design that we did not take in to account during the design of the interface. One of several failures was a lack of visible options to do certain actions. An example was the lack of a "delete" button on the Library screen for removing entries from the Library; although some users "knew" that it may be possible (and logical in the context) to press the "delete" key on the keyboard while highlighting the entry, the lack of a button to do so did bother some of the users.

One of the most confusing elements for the users (and one of the more critical elements to the program) was the tool allowing the users to split a downloaded set of pages (which may contain one or more entries that may or may not begin and end at page boundries). It became very difficult for the users to split the entries as they wanted to. We had hoped that they might see the use of the lined arrow selectors and use them to select their entry, since we saw this way of interacting as a way for the user to directly manipulate the selection process. In part their confusion stemmed from the fact that, usually in hi-fi interfaces, the selected portion is highlighted somehow, which we could not emulate effectively in our lo-fi prototype. In any event, even falling back to using the "Mark Start" and "Mark End" buttons proved to be an unusable alternative as well, where none of our users reacted in the way we expected. We believe this may have been due to the modal nature of the buttons, where, when one clicked on the "Mark Start" button, nothing indicated that the "Mark Start" mode had been entered; the same thing happened in the case of the "Mark End" button. We found that a more obvious selection scheme would be better. Possibilities attempted by the users included dragging from start to finish of a section, or clicking immediately on the images.

Also, we observed the effects of where a user's locus of attention may be. One of the users, for instance, did not happen to see the check box which said "Check here to open your browser after posting your blog" and thusly was surprised when the computer reacted this way after he "posted" his journal entry. There we saw that this element, for instance, must be made more obvious to the user. However, we do not think that this interface element needs not be a "critical decision" element, where the user must make a decision before any work continues, as the result of the lack of attention is non-destructive.

There was an element that we now are considering adding to the interface because of a shrewd observation made by one of our users, Moe. He said that he might want to retroactively remove lines from entries he made, so that, for instance, confidentiality may be preserved, since this information was going to be made available online. We never considered this possibility, but, seeing as editing pen-and-paper writing is difficult, we believe we should add this functionality to our design so as to reintroduce the affordance of easy editing to the bloging interface that is available in the keyboard-computer interface.

The lo-fi prototype does not allow several features that may have made our interface more usable. One example is the highlighting in the page selection dialog, where we could not emulate the interface well enough to make clear our "selection" intentions. Also, we found that, since we really wanted to see what was the most common interface to access the program, we made a taskbar icon and start menu for the program, which none of the users utilized to access the program.

Appendix

Consent Forms

Interview Videos

• Lo-Fi Prototype Sessions - BlogPad Trials - Video

Notes from Interviews

Subject 1:

Task 1:

• User wanted confirmation after saving to local disk

Task 2:

• For group: didn’t ask user to do initial setting
• User had trouble figuring out the posting interface (posting interface is where the user select what to post) - two failed click attempts, half minute of confusion. "Major usability problem: important to fix", User confusion makes it likely for users to just abandon the software.
• User spoke what he wanted to do (mark start and end of post), but did not find the way to do it as intuitive.
• Improvement: add a default folder name for local copy for the upload to blog screen. "Minor usability problem", slightly quicker process available for the user
• Improvement: make a paper prototype browser window, "Cosmetic problem" - just looks nicer.

Task 3:

• Improvement: change “blog” to “pages” in posting interface, "Cosmetic problem" - typo/writo
• Posting interface, especially usage of ‘mark start’ and ‘mark end’ are not clear to user (Where to place end arrow?)
• After the first post, the process went a lot smoother
• User zoomed through the upload process the second time, almost no pauses to even re-read the dialogs.

Afterthoughts:

• User expected to see confirmation for files being saved immediately after pen was docked, "Minor usability problem" - confirmations are good for the user.
• Library-Preview: list of images might become enormous - scalable? may need folder tree structure.
• User would like a ‘delete’ button for library entries, "I don’t agree this is a usability problem." - the keyboard's delete button works just fine.
• Have ‘jump to blog’ button clickable on most pages, "Minor usability problem" - convenient for the user.

Subject 2:

Task 1:

• User had only one pause longer than 10 seconds, which was on the initial screen,
• Note: the initial screen did not cause a pause on future attempts in the other tasks.
• User thought the process was easy.

Task 2:

• User attempted to click on the pages to select an area, then tried to drag and drop the buttons. This is likely due to a "pushable" paper button not looking different from a paper icon. "Cosmetic problem" - likely due to the paper prototype
• Improvement: move the sidebar to the left side of the screen, so that users would read the "Start selection" and "End selection" buttons first. "Major usability problem: important to fix" - less confusion for users, who were interacting with the left side of the screen before the right side, even though they needed buttons on the right side.
• User wanted a scratch tool so he can black out portions of what he wrote, "Minor usability problem" - added bonus features.
• User did not realize why a browser window was popping up (it was a checkbox in the setup screen)
• Improvement: have a checkbox directly above the final "Post to blog" button that allows the user to select whether he wants his posting to pop up in a browser or not. Major usability problem: important to fix" - confusion for user; must make the cause of this consequence more obvious and controllable.
• User quickly clicked the equivalence of a "next" button after a quick glance, uninterested in reading the whole screen or exploring other features.

Task 3:

• Fifteen-second pause while the user didn't know what to do with the browser after it popped up after posting
• User wanted to have an easier way to post multiple blogs, "Minor usability problem" - from our admittedly limited sampling, few users have multiple blog accounts. We can choose to support this, or not.
• This user used the ‘mark start/end’ buttons correctly on first try

Afterthoughts:

• User wanted to manage postings offline, and then go online and post multiple entries at once. "Major usability problem: important to fix" - convenient to the user, and not needing connectivity is one of the affordances of the pen interface, so we should try to keep this affordance.
• User wanted tool for blacking out text, and changing text color in posting interface. "Minor usability problem" - People can just cross things out with their pens.

Subject 3:

Task 1:

• No pauses longer than 10 seconds.
• User did not entirely read every screen.

Task 2:

• User was as a bit overwhelmed by the library-preview screen (reacted “woah”)
• User tried to highlight pages instead of using the ‘mark start/end’ button
• User mentioned that fewer steps would be better for this process, "Minor usability problem" - We will compress things into as few steps comfortable to users.
• User quickly clicked the equivalence of a "next" button after a quick glance, uninterested in reading the whole screen or exploring other features.

Task 3: (instead of posting multiple blogs, save 1 local and post another to LJ)

• Failed using ‘mark start/end’ tool by directly clicking on screen first, and then click the ‘mark start/end’ button
• First user to use the back button
• Improvement: eliminate the "Snap to boundary" buttons. Replacement functionality provided by location where start/end markers were placed: in between pages automatically snaps to boundary, and middle of pages cuts the image. "Major usability problem: important to fix", this modal interface has troubled all of our users. Replacing it with a natural mapping
• Improvement: Change Publish/Export button into two different buttons - "Major usability problem: important to fix", although currently we have 1 button for saving externally and 1 button for saving internally, publishing to blog and exporting are sufficiently different actions so that it would be clearer to have separate buttons.

After thoughts

• Support multiple blogging sites? This user has accounts with multiple sites.
• Make “open blog after posting” check box in ‘setting’ more visible