Whatever direction this goes in, I think it bears considerable thought and research. For example, Yahoo Meme offers a repost button along with a "reposts" stat (not unlike the Retweet chicklets going around):
http://www.flickr.com/photos/factoryjoe/3880766540/ http://www.flickr.com/photos/factoryjoe/3880767764/ Meanwhile, Tumblr has long had a "reblog" capability: http://www.flickr.com/photos/factoryjoe/3880772126/ This behavior is not new — but may not have prior precedent in formats/feeds. in-reply-to may be the current "mode", but it's unclear whether that is differentiated sufficiently from the original purpose, which was to show a response or reaction to a post, rather than a resyndication/further propagation. Perhaps the distinction is meaningless, but before deciding on anything (but the UI, per se), I think it's worth looking at previous examples of this behavior, and how it's been internalized by communities. Reinvention in the enemy of standardization. Chris On Tue, Sep 1, 2009 at 11:06 PM, Mr. Meitar Moscovitz <[email protected]>wrote: > On Sep 1, 2009, at 3:03 PM, Craig Andrews wrote: > > What do we all think about the re-dent implementation in this merge >> request? http://gitorious.org/laconica/mainline/merge_requests/1391 >> >> I've seen a lot of discussion... but I'm not aware of any consensus. >> >> ~Craig >> > > So, from what I gathered in the discussions about this feature so far, the > major sticking points are: > > * Use plain language; terminology like "redent" and "retweet" are > alienating jargon. Hence, the merge request uses the recycling symbol to > avoid service- or brand-specific iconography, and the term "repeat" to avoid > jargon and stick with plain English. (It seems "reshare" as well as > "forward" are other options for less jargon-y terms to replace "redent". > Personally, I like repeat best.) > * Do not automatically send a notice without giving the user a chance to > edit it first. The merge request uses the implementation of the "reply" > functionality as a blueprint for the repeat functionality, so it doesn't > send any notices implicitly. > > There doesn't seem to be any clear consensus on how to distinguish the > repeated notice from other kinds of notices. A simplistic option is to use > in-reply-to (which is what this merge request does). > > There also doesn't appear to be much consensus on how this should be > exposed graphically, so I took the route I saw Identi.ca *client* apps > using, which was the addition of a new button. > > Admittedly, I think this is a pretty low-tech solution since it's entirely > client-side and user experience focused, but I actually think that's the > best way to start figuring out whether or not more sophisticated > functionality in the database or OMB protocol itself is needed. That is to > say, this button scratches my itch for the time being and I want to see how > other people react to it. :) > > Cheers, > -Meitar Moscovitz > Personal: http://maymay.net > Professional: http://MeitarMoscovitz.com > > _______________________________________________ > Laconica-dev mailing list > [email protected] > http://mail.laconi.ca/mailman/listinfo/laconica-dev > -- Chris Messina Open Web Advocate Personal: http://factoryjoe.com Follow me on Twitter: http://twitter.com/chrismessina Citizen Agency: http://citizenagency.com Diso Project: http://diso-project.org OpenID Foundation: http://openid.net This email is: [ ] bloggable [X] ask first [ ] private
_______________________________________________ Laconica-dev mailing list [email protected] http://mail.laconi.ca/mailman/listinfo/laconica-dev
