[
https://issues.apache.org/jira/browse/WAVE-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031507#comment-13031507
]
David Hearnden commented on WAVE-267:
-------------------------------------
In Google Wave, the inability to delete the root blip is purely a UI
restriction. The underlying model does not prevent its deletion, and I think
it would be too difficult to attempt enforcing it at the model level.
We found that the ability to delete the first blip had a number of usability
issues. The first blip is special in terms of behaviour (it's the blip from
which a title is extracted), and also user association: the author(s) of the
root blip are thought of as the author(s) and owner(s) of the wave as a whole.
If/when that authorship changes, the identity of that wave in our mental models
is disturbed.
I think that our feelings about how the root blip should behave comes from the
impedance mismatch of Wave's one-communication-model-to-rule-them-all approach.
In a collaborative document environment, then the root blip gives the wave its
identity, and so deleting it seems like violating the wave. In a
conversational / chat environment, however, then the root blip is not that
special at all, so being unable to delete can sometimes seem like an
unnecessary restriction. Thinking on a grander scale, I think the right way to
overcome this mismatch is to have alternative UIs for different interaction
modes, but backed by the same data. So you could start a Wave with a
discussion UI (where root blip deletion is perhaps possible), but if the root
blip emerges as a collaborative document, then you could switch to a different
UI that is more suitable for that experience (and in which root blip deletion
is disabled), etc. That's obviously not a short term solution though.
On balance, I think Google Wave's behaviour is mostly right, but perhaps that's
just because I'm used to it:
*) It's infeasible to prevent any blip from being deleted at the model level,
especially under concurrent scenarios.
*) Throughout the lifetime of the wave UI, whichever blip is in the root
position should have its Delete link removed or disabled (and the keyboard
shortcut should be inactive), in order to make it difficult for the root blip
to be deleted.
*) In the rare scenario when a wave exists with no blips, then I think:
- the rarity of the scenario diminishes the importance of having a good
solution, and
- having the reply box create a blip (which would also be a new root blip)
seems to make sense.
I'll give a quick summary of how this is done in Google Wave. I think it's too
heavyweight for this particular issue (root blip deletion), but I certainly
don't object to it. If it is in scope for WIAB to have different editability
modes, read-only participants, etc, then maybe it's a good idea to nail it
upfront.
Google Wave's mechanism for controlling which UI actions are enabled/disabled
on particular bits of UI is as follows. The UI is already tree structured: the
main conversation contains participants and a thread, threads contains blips,
and blips have gadgets, other threads, and other (private) conversations as
replies, etc. In parallel, the UI code maintains a tree of editability
objects, at the same granularity as those UI components, where each editability
object reveals which actions are enabled/disabled. The association between
editability objects and UI components is live: as the editability changes, the
corresponding piece of UI is updated to enabled/disable the appropriate
controls. The tree structure provides a restriction model, so that, for
example, making the whole wave UI read-only simply means setting the top-level
editability object to read-only mode, which implicity causes all the descendant
ones to be restricted by that (so they all become read-only too). Or making a
particular thread comment-only (so that participants can add new blips, but not
delete or edit existing ones) also requires changing just one editability
object, implicity restricting all descendants.
For the range of editability modes that either exist or were trialled in Google
wave (read-only participants, non-deletable blips, writable conversations with
read-only private-conversations, writable gadgets in read-only blips,
participants that can edit but not add others, comment mode, etc), that
unifying model made sense, and I think worked pretty well. If WIAB has enough
editability modes, I think it's a good solution. But for doing just the
root-blip deletion prevention, an ad-hoc solution would be more pragmatic: the
paragraph above is just for reference.
> Deleting the only blip in the root thread is not handled well
> -------------------------------------------------------------
>
> Key: WAVE-267
> URL: https://issues.apache.org/jira/browse/WAVE-267
> Project: Wave
> Issue Type: Bug
> Components: Web Client
> Reporter: Michael MacFadden
>
> When you create a wave the root thread contains a single blip by default. If
> you delete this blip right off the bat several strange things start to
> happen.
> First Case:
> 1) Create a new wave.
> 2) While still in edit mode click the delete link in the single blip.
> 3) The reply box is not shown.
> At this point without refreshing the browser you can't create a new blip. If
> you now click on another wave, you get a shinny. If on the other hand you
> refresh the browser the reply box comes back.
> Second Case:
> 1) Create a new wave.
> 2) Click edit to get out of edit mode.
> 3) Click the delete link.
> 4) Click the reply box.
> We get a shinny.
> I am not certain what the correct behavior is, but I am sure this is not it.
> Should we prevent the user from deleting the blip if it is the only blip in
> the root thread. I don't see a case where a conversation with no blips is
> useful. If we do want to allow the user to delete this blip, the what is the
> UI metaphor for creating a new blip in an empty thread. The reply box is
> probably not correct since you aren't replying to anything.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
