incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <>
Subject Re: [Apache Bloodhound] #138: Widgets wiki macro
Date Thu, 19 Jul 2012 12:15:54 GMT
#138: Widgets wiki macro
  Reporter:  olemis     |      Owner:  olemis
      Type:  task       |     Status:  accepted
  Priority:  major      |  Milestone:  Release 2
 Component:  dashboard  |    Version:
Resolution:             |   Keywords:  wiki macro embed widgets

Comment (by jdreimann):

 Replying to [comment:8 olemis]:
 > Replying to [comment:5 jdreimann]:
 > > Ok, I'll raise some new tickets specifically to find ways to make it
 easier to discover macros. This will be all the more important and
 difficult when plugins provide these widgets.
 > I've mentioned some times before (somewhere else , before ''Bloodhound''
 project started ''';)''' that the approach I suggest to improve
 WikiFormatting user experience involves using one of ''CKEditor'' ,
 ''TinyMCE'' , ... or any other pluggable rich text ''WYSIWYG'' web editor
 . I have at least one example I can show for all those interested on the
 details .

 Sure, but that's not directly related to this. Displaying formatting
 options is much less complex than widgets: They have more variety and
 complexity themselves.

 > > I'm also concerned that the look of a view such as 'compact' is still
 in a state of flux
 > ?

 What this compact style looks like may change significantly within a short
 time period after Bloodhound gets some traction and we find out what works
 and what doesn't. How the 'compact' widget displays TicketGroupStats for a
 given Milestone in your example isn't defined at all by the query (and I
 don't believe it should be). This could be confusing and frustrating for
 users that use the feature until the widgets have reached a certain

 > > I would be more comfortable with an approach that whitelists widgets
 that can be added in this way
 > -1 IMO . If there's something that needs to be improved then let's
 create tickets

 See above for the risks of the current approach. Also, 'let's create
 tickets' means we're essentially committing to a unknown amount of future
 work to maintain and improve this functionality (and the expectation that
 this will be dealt with). That would be fine if we had strong community
 support for this feature, ie it's much requested and used, but until then
 we're just creating future commitments that divert attention from the
 things we really need to focus on.

 > > until we have a solid framework within which to allow all to be
 > What does this mean exactly ?

 For example a clear way for 'hacks' to provide widgets, how version
 changes in widgets will be dealt with, permissions of who can embed them,
 how they can be discovered without needing to refer to documentation, how
 the documentation itself will be extended by hacks.

 Ultimately this doesn't seem like a core feature of Bloodhound to me yet,
 but rather something a plugin should provide, if it's done in the near

Ticket URL: <>
Apache Bloodhound <>
The Apache Bloodhound (incubating) issue tracker

View raw message