#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:3 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
user.
> > ... kind of ...
>
> Could please you clarify what the purpose is if my interpretation isn't
correct?
>
Take my previous comment as a ''yes , as far as I understood'' . But,
considering the fact that your initial statement is a bit generic and may
be interpreted in different ways in first place (i.e. I write about what
I think you said, and you reply considering what you think I said), please
beware of the fact that a (yes | no) answer might not be accurate to
express my opinion.
> > > 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 .
>
> That would suggest that the only widgets allowed are ones that
essentially display the results of custom queries.
>
when I said so , the ... is used to briefly omit further similar
statements like ''when you render a report you'll get a list of tickets ''
, ''when you render ticket stats you'll get a progress bar'', ''when you
render a .PNG attachment you'll get a picture'' , and so on .
> > > 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.
>
That's another approach , yes . Let's see it from a different perspective
. If a decision has been made by a team to render another widget (let's
assume it's already implemented) or the same widget but with different
arguments (e.g. different columns in query widgets) then ... why should
they implement a plugin to (extend | override) default dashboard ?
Besides please consider reading [http://mail-archives.apache.org/mod_mbox
/incubator-bloodhound-dev/201207.mbox/%3cCAGMZAuOB-rZ9+UMFGD7KRG-wn+1ea-
_w5x2ltoenh7ch5rv...@mail.gmail.com%3e this message] actually started by
Gary and related to role-specific (e.g. user groups) dashboards and other
similar use cases , IMO requiring extra flexibility.
> > ... so what's the problem about that ?
>
[...]
> I think you've gone off track here.
this is why I said ''... kind of ...'' above . When replying to generic
statements it's always possible that the parties involved in the
conversation have different ideas , thus misunderstand parts of the
conversation or talk about the same '''thing''' but thinking about them
from a different perspective . Now I recall some pictures in
[http://www.amazon.com/Object-Oriented-Analysis-Design-Applications-
Edition/dp/0805353402 Grady Booch's book] ''';)'''
> 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.
>
Well , maybe you have a point here . It's possible that the project won't
deliver the whole dashboard configuration web UI and further artifacts
needed (though IMO it should) ... maybe ... but it should at least the
barely minimal requirements are to provide clear extension points allowing
to customize dashboard contents . Right now all that turns out to be hard-
coded , and that limits the potential of the underlying infrastructure .
> > > 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.
>
... but some of them do it . And that's a good example because that's a
reason why I like my shiny ''Android'' smartphone ''';)''' . I even use
[https://play.google.com/store/apps/details?id=ch.jamesclonk.android.ringtonerandomizer&hl=en
this app] this randomize a lot of ringtones, and I don't need to implement
anything like a plugin to decide which ringtones I want to enable at a
given time. Besides I use
[https://play.google.com/store/apps/details?id=com.ringdroid&hl=en this
one] to create my own ringtones . IOW even if default ''Android'' settings
tool doesn't allow for doing this, it's possible to do so and I want to
(... and those apps are so lovely that it almost hurts ''';)''' . You'll
notice that there are ''165,279'' votes for ''Ringdroid'' averaging
'''4.6''' , and ''299'' votes for ''Ringtone Randomizer'' averaging
'''4.2''' ; and in the later case mainly not that much just because there
are quite a few similar apps, some of they supported, more comercial , and
... ''';)'''
> > 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.
>
IMO it'd be awesome if plugins are able to insert widgets in dashboards at
plugin environment setup or upgrade time ... but let them decide what
widgets to insert in there afterwards .
> > (...) 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'm not sure that ''working towards'' is accurate . I'd rather say
that they were the inspiration for the design of widgets architecture in a
way similar to modern technology inspired on ''DaVinci'' devices ''';)'''
http://www.google.com/ig/directory
https://developers.google.com/igoogle/
http://code.google.com/igoogle/dashboard/
http://en.wikipedia.org/wiki/IGoogle_Gadgets
... and jftr there is also this ''Apache'' project named
[http://incubator.apache.org/projects/shindig.html Shindig] , which is
related to the subject . But like I said , the goal is not to reinvent
gadgets so e.g. synergies and integration between both projects are off
topic; so far we don't even have a need of any kind to use a gadget
container . The idea is to consider their success and experience in the
field in order to reuse all that knowledge while building our ''API''s .
> I can't recall this being discussed on the mailing list. Maybe improving
WikiMacros significantly may be a more worthwhile cause?
It's the same cause , trust me . And it is by design since the first time
I started ''API'' design . To me improving WikiMacros means building
widgets and embed them using WidgetMacro ''';)'''
--
Ticket URL: <https://issues.apache.org/bloodhound/ticket/140#comment:4>
Apache Bloodhound <https://issues.apache.org/bloodhound/>
The Apache Bloodhound (incubating) issue tracker
