Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#140: User-defined dashboard contents. -+- Reporter: olemis | Owner: Type: | Status: new enhancement| Milestone: Priority: minor |Version: Component: dashboard | Keywords: dashboard configuration database Resolution: | markup preferences admin -+- Changes (by olemis): * owner: franco = * status: assigned = new -- Ticket URL: https://issues.apache.org/bloodhound/ticket/140#comment:9 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#140: User-defined dashboard contents. -+- Reporter: olemis | Owner: franco Type: | Status: assigned enhancement| Milestone: Priority: minor |Version: Component: dashboard | Keywords: dashboard configuration database Resolution: | markup preferences admin -+- Changes (by olemis): * status: accepted = assigned * owner: olemis = franco Comment: I'm assigning this ticket to franco . He'll start working on this after #280 . -- Ticket URL: https://issues.apache.org/bloodhound/ticket/140#comment:8 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#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 gjm): Replying to [comment:4 olemis]: 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. I'm afraid that I am not convinced by this argument. Putting all the functionality into the single dashboard view was not what I was advocating. In the long run it may be seen as worthwhile to provide this flexibility but my suggestion was to provide different standard views. Part of the advantage of this would be that a user should not need to discover or build the most appropriate dashboard for themselves yet. We can provide more standard views that everyone (or at least everyone with appropriate permissions) can view. I think it would be better to shelve this discussion until a point at which we are ready to consider further generalisation of the dashboard. It is not that it is completely undesirable but there are more important things to get on with. -- Ticket URL: https://issues.apache.org/bloodhound/ticket/140#comment:5 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#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:5 gjm]: Replying to [comment:4 olemis]: 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. I'm afraid that I am not convinced by this argument. Putting all the functionality into the single dashboard view was not what I was advocating. I'll clarify something here . My suggestion does not consist in including widgets in a single for developers, team leaders, ... any other role , in order to satisfy any possible expectations . No. My suggestion is to have a single ''URL'' to access dashboard and make it look like a home page. Nonetheless view should be able to adapt according to user decisions on what's important for him regarding products and associated resources. In the long run it may be seen as worthwhile to provide this flexibility good but my suggestion was to provide different standard views. as long as they'll be accessible at a single URL this doesn't conflict with my previous suggestion because ... Part of the advantage of this would be that a user should not need to discover or build the most appropriate dashboard for themselves yet. We can provide more standard views that everyone (or at least everyone with appropriate permissions) can view. ... if the infrastructure for custom dashboard contents is somewhere then we can give the option (admin and|or preferences panel) for users to select between a set of built-in dashboards provided by the project and designed for particular use cases . That'd be fine in first place . Maybe later a separate plugin might extend these capabilities in order to let them design all the details at will, select widgets one-by-one, etc ... Nonetheless in any case we'll need customized dashboards and a mechanism to select what are the contents of interest for a particular user . You can see it this way too . It'll be possible to have multiple dashboards delivered by the project or plugins e.g. /dashboard/ticket , /dashboard/team , /dashboard/vcs , ... but users will be able to see them listed in a form (admin or preferences panel) and select the one they'll see by default on accessing /dashboard path . I think it would be better to shelve this discussion until a point at which we are ready to consider further generalisation of the dashboard. It is not that it is completely undesirable but there are more important things to get on with. We shall keep this ticket unscheduled until it will be the right time to start working on it . -- Ticket URL: https://issues.apache.org/bloodhound/ticket/140#comment:6 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#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 user. ... kind of ... Could please you clarify what the purpose is if my interpretation isn't correct? 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. 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: https://issues.apache.org/bloodhound/ticket/140#comment:3 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#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
Re: [Apache Bloodhound] #140: User-defined dashboard contents.
#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): 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. I believe that any such system should be some way out - it needs a certain stability of what the user can expect in each widget, nevermind a collection of worthwhile widgets, and a clear upgrade path should the dashboard change significantly. There are more reasons: Users may dismiss a widget early on because it doesn't yet provide the functionality they expect, and not revisit it later. 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. The ultimate argument I see against this at this time though is that #138 already provides similar functionality and challenges. If we're committed to fixing them, we may as well start there first. -- Ticket URL: https://issues.apache.org/bloodhound/ticket/140#comment:1 Apache Bloodhound https://issues.apache.org/bloodhound/ The Apache Bloodhound (incubating) issue tracker
