incubator-bloodhound-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Apache Bloodhound" <bloodhound-...@incubator.apache.org>
Subject Re: [Apache Bloodhound] #140: User-defined dashboard contents.
Date Thu, 19 Jul 2012 01:31:02 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 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 user.
 >

 ... kind of ...

 > I believe that any such system should be some way out

 if I understood the meaning of this correctly then I'd state I disagree

 > it needs a certain stability of what the user can expect in each widget,

 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 .

 > 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

 > 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 .

 > 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 . 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. Even if so far they
 have been able to simulate dashboards by using a macro embedding
 ''iGoogle'' gadgets (i.e. equivalent to ''WidgetMacro'' ) , those
 scenarios do not take positioning into consideration. This happens mainly
 because WikiFormatting , unlike layouts, is not designed for that
 particular purpose.

 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
 ''';)'' .

 > The ultimate argument I see against this at this time though is that
 #138 already provides similar functionality and challenges.

 Not quite . Widget macro is about quickly rendering all kinds of content
 in documents (supporting WikiFormatting ''';)''' . OTOH this is about
 allowing users to watch exactly the contents they decide are important in
 dashboard views . More like some kind of ''iGoogle'' , ''Netvibes'' , ...

 > If we're committed to fixing them, we may as well start there first.

 Completely agreed . That's why I didn't suggest scheduling it for current
 releases. The right time is TBD ''';)''' .

-- 
Ticket URL: <https://issues.apache.org/bloodhound/ticket/140#comment:2>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker

Mime
View raw message