Why build a different preview mechanism? Just fire up the console as if that's the way the command had been accessed in the first place. That way the entire user experience is consistent and development effort can be focused on a single interface.
Marcus 2009/7/10 Brandon Pung <[email protected]> > Oh gotcha, so you were referring to using the ubiquity context menu > (accessible through right-clicking). I agree we need some sort of preview > mechanism built into that menu as well. It's something we've discussed, and > I'll bring it back up. Also with regard to sending a page url to a friend by > right clicking on the page and using the ubiquity context menu, I think > that's something we should add support for. Perhaps when you use the > right-click context menu, the url of the current page should be considered > "selected" if nothing else is selected. I'll think about this. Thanks! > > -Brandon > > > On Fri, Jul 10, 2009 at 9:41 AM, Marcus <[email protected]> wrote: > >> Hi Brandon, thanks for your response. >> >> What happened is that I highlighted the URL on the page, then >> right-clicked, went to the Ubiquity menu, and clicked Twitter... which then >> posted the URL all by itself straight to Twitter with no opportunity to >> edit. >> >> I would expect the above actions to have the same results as doing it via >> the console in the way that you describe (and that should go for all >> commands) >> >> Furthermore, how is one supposed to execute a Ubiquity command on the >> current page (or iframe) - e.g. to send the current page URL to a friend? I >> would expect there to be a Ubiquity submenu on the standard page/frame >> right-click menu but there isn't one... or is that simply because there are >> no appropriate commands? >> >> >> Marcus >> >> >> 2009/7/10 Brandon Pung <[email protected]> >> >>> Hi Marcus, >>> >>> Thanks for the feedback. I really like your recommendation for providing >>> an easy way for users to provide feedback to command developers on their >>> commands using a streamlined mechanism built into Ubiquity. I'll bring this >>> up at our next meeting =) With regards to the preview/edit facility, >>> ubiquity does currently have a preview pane which should show what each >>> command is about to do. For example, if I highlight the url " >>> http://ubiquity.mozilla.com/"; and open ubiquity and type "twitter" the >>> preview pane for the twitter recommendation will say "Updates your twitter >>> status to: http://ubiquity.mozilla.com";. I could then change my ubiquity >>> input to "twitter check out ubiquity this" and the preview pane says >>> "Updates your twitter status to: check out ubiquity >>> http://ubiquity.mozilla.com";. Is this pane not working correctly for >>> you? Let me know if I had misinterpreted that second question. Thanks again! >>> =) >>> >>> -Brandon >>> >>> >>> On Fri, Jul 10, 2009 at 7:20 AM, MarcusT <[email protected]> wrote: >>> >>>> >>>> I've been playing with Ubiquity for 24hrs and it seems like a great >>>> concept but is rather rough around the edges. >>>> >>>> What's most missing right now from a test user perspective is the >>>> ability to provide feeback (which may or may not be bugs) on specific >>>> commands in a consistent way - e.g. I would like to make a few >>>> suggestions about the Twitter and Map commands, but will have to work >>>> out where to post that feedback to, and how... instead there should be >>>> a "feedback" link next to each command in the command list which would >>>> allow me to reach a page where I can post that feedback and be sure >>>> that the author will at least see it, if not respond to it. I am aware >>>> of the Get Satisfaction facility, but there's no guarantee that the >>>> author of a 3rd party command will ever look here. Instead, Mozilla/ >>>> Ubiquity needs to provide a standardised mechanism for providing >>>> feeback, but I realise this could be a lot of work. In the short term, >>>> it should be ensured that all commands must have an email address >>>> listed within the Ubiquity command list so that feedback can be >>>> directly provided to the relevant author that way. >>>> >>>> Secondly, it's crucial that commands provide a preview/edit facility >>>> (within a consistent, standardised interface framework provided by >>>> Ubiquity) before they commit a change - e.g. I just posted a URL that >>>> I had highlighted via the Twitter command... I had assumed that it >>>> would provide me with the opportunity to add a comment to the URL, but >>>> instead it just posted the URL. This is NOT useful to me, nor is it >>>> predictable for new users. >>>> >>>> Finally, it should be possible for commands to have configuration >>>> options (e.g. Twitter command could have a "preview before post?" >>>> option defaulted to ON, which advanced users could switch off if they >>>> decide that they don't need it), and again, these options should be >>>> presented within a consistent, standardised interface provided by >>>> Ubiquity. >>>> >>>> >>> >>> >>> -- >>> Brandon James Pung >>> Massachusetts Institute of Technology Class of 2010 >>> Department of Electrical Engineering and Computer Science >>> 828.777.8640 | [email protected] >>> >>> >>> >> >> >> > > > -- > Brandon James Pung > Massachusetts Institute of Technology Class of 2010 > Department of Electrical Engineering and Computer Science > 828.777.8640 | [email protected] > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ubiquity-firefox" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/ubiquity-firefox?hl=en -~----------~----~----~----~------~----~------~--~---
