incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <>
Subject Re: [Apache Bloodhound] #140: User-defined dashboard contents.
Date Thu, 19 Jul 2012 14:41:44 GMT
#140: User-defined dashboard contents.
  Reporter:  olemis      |      Owner:  nobody
      Type:              |     Status:  new
  enhancement            |  Milestone:
  Priority:  minor       |    Version:
 Component:  dashboard   |   Keywords:  dashboard configuration database
Resolution:              |  markup preferences admin

Comment (by jdreimann):

 Replying to [comment:2 olemis]:
 > Replying to [comment:1 jdreimann]:
 > > From the description this seems to be a way to allow for more
 modifiable widgets, which could also be added or removed at will by the
 > ... kind of ...

 Could please you clarify  what the purpose is if my interpretation isn't

 > > it needs a certain stability of what the user can expect in each
 > so what's the problem ? when you render a report you'll get a list of
 tickets , and so on ... or maybe I misunderstood something .

 That would suggest that the only widgets allowed are ones that essentially
 display the results of custom queries.

 > > nevermind a collection of worthwhile widgets,
 > ... with time they'll be there ''';)''' . They won't if we don't provide
 foundation ''API''s to build them

 We can still allow plugins to extend the interface without having
 individual users modify their Dashboards.

 > > and a clear upgrade path should the dashboard change significantly.

 > I'd rather say a clear backwards compatibility / deprecation policy .
 > > There are more reasons: Users may dismiss a widget early on because it
 doesn't yet provide the functionality they expect,
 > ... accept enhancement proposals, since it may be improved ...
 > > and not revisit it later.
 > ... so what's the problem about that ? Person '''A''' can travel to
 location ''B'' and not to like it for tourism. So (s)he never comes back .
 Should we remove the notion of traveling and all related infrastructure
 from our world ? Should we constrain other people and force them not to
 visit that place ever ? Perhaps months later person '''A''' knows of a
 positive review once location ''B'' is more attractive and decides to come
 back again .

 I think you've gone off track here. This is about whether Bloodhound
 itself should commit to providing this functionality, not whether a plugin
 may provide it. The real question is if we should build the infrastructure
 and commit to maintaining it, when we give others the opportunity to do so
 regardless if our decision.

 > > To my knowledge evidence suggests that users do not regularly assess
 all available options and rationally decide on which ones to choose, which
 makes this a potentially very complicated system to maintain and support
 for a small proportion of users.

 > Even if first statement may be true , I don't agree on the conclusion .
 I've developed ''TracGViz'' plugin and since some time ago users have been
 smart enough to decide exactly what they want to see .

 I'm not doubting users intelligence here. What you're saying though is
 equivalent to a provider of ringtones to say that their customers don't
 have any problem using ringtones, while missing that the vast majority of
 mobile phone users never change their default ringtone.

 > No need to whitelist or blacklist anything , force a particular policy ,
 ... I do see a lot of use cases (especially when using plugins ''';)'''
 for users wishing to add other information in dashboard views.

 I'm more than happy for plugins to extend the dashboard views.

 > (...) From a more technical perspective, before I've mentioned that
 widgets are an intermediate step between WikiMacros and gadgets , so it
 turns out to me that we should provide something similar to the
 capabilities offered by ''iGoogle'' et al. (even if not that quite
 sophisticated , still usable ''';)'' .

 So what are these gadgets that we're working towards? I can't recall this
 being discussed on the mailing list. Maybe improving WikiMacros
 significantly may be a more worthwhile cause?

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

View raw message