zotero votebox?
I think it would be very useful if the Zotero site could implement something like Dropbox's "votebox," where people could vote for the features, fixes, etc. that they would most like to see implemented.
I am not saying that the developers should be obligated to prioritize whatever gets the most votes. And I do think there needs to be a hierarchy of decision-making for a project like Zotero to be successful. Usually the developers give good reasons for their conclusions about how the program should develop.
I also think that there is currently not a good way for the development team (or anyone) to know what is most important to the most users. Everyone has a different workflow. There is not always a solution or conclusion that is objectively preferable.
The forum is not a great way to get feedback. It is time-consuming to participate and I think people have to have a somewhat thick skin for these discussions.
I have great respect for Dan and Adam and other developers. You all are very responsive and open to input. However, sometimes a person will comment that they wish there could be change X, and the response will be along the lines of, "It's that way because of reason Y," or "no, I don't agree, it makes more sense to me the current way," and then it seems that there is no point in pursuing the issue. Or, 10 people might all post about some issue that they want addressed but no one on the development team responds, presumably because they don't think it's as important as other issues they're dealing with.
But if in fact hundreds of people want change X, there should be a way for the developers to know so that they can make decisions with some knowledge of user preferences. I assume that if 250 people voted that they want change X, the developers would want to know about it and would be open to reconsidering it, even if it didn't seem completely consistent with their opinion about UI design or whatever.
I agree with the development team's opinions almost all of the time. But I don't think that any person can really know what will work best for the most users without some feedback system.
Thanks!
I am not saying that the developers should be obligated to prioritize whatever gets the most votes. And I do think there needs to be a hierarchy of decision-making for a project like Zotero to be successful. Usually the developers give good reasons for their conclusions about how the program should develop.
I also think that there is currently not a good way for the development team (or anyone) to know what is most important to the most users. Everyone has a different workflow. There is not always a solution or conclusion that is objectively preferable.
The forum is not a great way to get feedback. It is time-consuming to participate and I think people have to have a somewhat thick skin for these discussions.
I have great respect for Dan and Adam and other developers. You all are very responsive and open to input. However, sometimes a person will comment that they wish there could be change X, and the response will be along the lines of, "It's that way because of reason Y," or "no, I don't agree, it makes more sense to me the current way," and then it seems that there is no point in pursuing the issue. Or, 10 people might all post about some issue that they want addressed but no one on the development team responds, presumably because they don't think it's as important as other issues they're dealing with.
But if in fact hundreds of people want change X, there should be a way for the developers to know so that they can make decisions with some knowledge of user preferences. I assume that if 250 people voted that they want change X, the developers would want to know about it and would be open to reconsidering it, even if it didn't seem completely consistent with their opinion about UI design or whatever.
I agree with the development team's opinions almost all of the time. But I don't think that any person can really know what will work best for the most users without some feedback system.
Thanks!
This discussion has been closed.
If I remember correctly, the developers have nothing against this if there is someone who volunteers to maintain the voting system.
As I said then:
https://github.com/zotero/zotero/issues
Once there is a well working and maintained tracker, I have no doubts that Zotero will link to the tracker from the forums.
Before suggesting something like this, you should have a response for two questions:
1) Who will maintain it
2) What will be done differently so that it will not end up dying like this attempt
http://forums.zotero.org/discussion/12945/give-this-a-try-for-user-feedback-zoterouservoicecom/
It is still the case that the developers profess to having a very clear idea of what users need and want; and that users have difficulty finding out what is planned, what other users have requested before, what proposals are being considered, and what developers have said in response to requests or proposals. In other words, there is still a disconnect between what devs know and can provide for, and what users know and should (or need not) ask for. If someone would come up with a solution to address this it would be great, but from past experience it is not going to be straightforward.
Beyond that, as the person ultimately implementing a lot of these requests, I don't really care how many people would vote for something. I implement something if I think it's a good idea, there's a good technical solution, and I have time to work on it. And I'm quite happy to engage in discussions about those things here.
For what it's worth, while I'm sure quickfold11 wanted to make the more general point, the post that (I assume at least partly) prompted this thread was in fact answerable by a basic search ('search delete clear'), which would have led to a succinctly named thread ("Quick filter/search box reset when item added or deleted") that included links to the relevant issues on GitHub and an update from me when a patch was checked in. I don't think there's all that much to improve upon there, process-wise. But that search would've worked only on the built-in forums search. I've been asking Faolan for a while to drop the fairly useless Google-powered search in the navbar and revert to always using the Vanilla search, which is the only one I ever use. I think that change is coming with an upcoming site update, and that may go a long way towards helping people find relevant threads.
I don't think there's much more to say on this that wasn't covered in the other thread. The general consensus seems to be that the things that would be most helpful would be 1) the ability to highlight important posts within forum threads at the top of the threads, the way some other forums work and 2) a wiki page that outlined some of the more popular feature requests and provided a status summary with links to relevant forum threads. The former requires Faolan or someone else writing a Vanilla plugin to do it, if one still doesn't exist. The latter could be done by anyone—but, then, that was also the case a
couplefew years ago, when it was first suggested.I've been thinking about the possibility of assigning index terms to each post. I am mainly thinking of this for my own site but I believe that it could work here. Zotero already asks that messages to the forum be assigned to categories. If there could be a requirement that each poster also add terms from an index list (sub- categories?) some of the jumble of search results might be cleared. Instead of only the first poster having control of the topic category, the poster of each reply would assign terms to her or his comment.
Having spent some more time looking at Mendeley's implementation of UserVoice over the last year, I've come to agree with Dan in his main critique of it: It's a bad place to communicate with users - if you look at the actual comments, many of them could actually be addressed relatively easily in a forum thread, or they'd require some back and forth to hash out details etc. As a venue for feature requests, it does more harm than good.
I still very much agree with mark's main reason for suggesting it - I don't think Zotero does a good job communicating to users what the current status of some of the most frequent requests/concerns is (FWIW I don't even think it does a very good job communicating _existing_ features - my bet would be that 50%+ of all users have no idea about the pretty awesome "Store References in Document" feature, for example).
If someone wants to start a wiki page for that - the top 20 most frequent requests and their status or so - I'm happy to help maintain it.
That's a different concern from the one expressed by quickfold - i.e. that Zotero devs don't have a way to get good feedback from users - that's hard to know, but reading almost the same number of threads that Dan does, I think I can safely say that you get a pretty good sense of what comes up frequently. Sure, Dan doesn't know whether something is requested by 50 or 500 people - but as he says, that's not the most relevant piece of information anyway.
I know there's a translator request thread, but it was never stickied so it's essentially lost to the user that drops by the forum.
A wiki page would be almost the same, but I would argue that the forums are much more visited and a sticky at the top of the category would be more visible and more frequently updated. Plus, I would suggest keeping the thread clean (maybe even locked) and providing very succinct information on each feature request (description, status, etc.), including declined features, and linking to the main thread for further discussion. One problem I can see is that taking over the thread (i.e. the first post) after the initial maintainer decides to abondon it could only be done by a moderator/admin, which is where a wiki page would fit much better.
Perhaps we can create a fake sticky thread that links directly to a wiki page??
Either way, I would really like to see what features need to worked on.
Finally, I think a similar wiki page/thread would be useful to list for goals for the next major Zotero release. Not as important, but I think it might attract more community developers.
(BTW - I thought custom fields were out completely, but Dan has mentioned that it might still be something that could happen in the long run if the various issues are solved)
@Dan - yes, I know. That's why I mentioned that as an option.
Also added a bunch of feature requests. I went through the 100 most recent posts and picked out some feature requests that have been discussed. I threw in a couple feature requests that I remember reading about previously, but I'm sure I've forgotten a lot of them. I'm not sure if all of them are worthy of being on the list, so feel free to remove them.
This is clearly not meant to be a final copy. I got a little tired of browsing through the forum, so if someone else wants to chip in and fill in some blanks, that would be wonderful. Otherwise, I will get back to it tomorrow.
Thoughts on the format, usefulness, etc. of the list??
http://www.zotero.org/support/requested_features
My biggest concern currently is how to highlight that "future version" means "don't bet on this happening in the next couple of years". Raising false hopes annoys people.
Two ideas
1. Instead of "Planned for future versions" we write: "Not planned for medium term. Possible implementation in future versions (>>24months)" or so.
2. We go back to your first idea and put those items in a separate part of the page & write a brief note along the lines above.
Alternatively, if the goal is really to present a much wider set of planned features in a more user-friendly way (and also not have average users posting to GitHub), we could use the GitHub API to present the full issues list in some searchable, read-only fashion, with links to forum threads extracted from the descriptions.
My first post assumed that the developers did care what was most important to their user base. In fact, I assumed that a grant-funded open-source project like Zotero was driven by an aim to produce something that is the most useful for the most people. If hundreds of people think it is important to implement feature X, but Dan doesn't think the feature is elegant or intuitive or whatever, then that's the end of it? Dan certainly knows more that the users about technical possibilities, the project's resources, etc., but solely in terms of whether a feature of the program is desirable or should be given more attention, why is Dan's individual judgment more important than the collective opinion of the user base who actually use Zotero every day as a central part of their workflow? It is not just a numbers issue. I assume that the developers work on Zotero frequently or daily, but also that they do not regularly use it for hours each day as a reference tool for writing research. My apologies if this is not the case. If it is, however, then I'd propose that what seems like a good idea conceptually may not seem like a good idea to a person who is actually using the tool to perform hundreds of operations a day/week/year.
As I said in my original post, there are a lot of things that do not have objective best answers, and I would hope that the developers would agree. Perhaps the response to this post will be the common open-source response of "if you want it, do it yourself." I have offered to help with the project as a non-programmer, but I'm not a programmer. I'm a humanities researcher. If there is a way for me to maintain a votebox without doing programming, I'm volunteering right now to do it (or at least to help, depending on the magnitude of the project). I don't know whether the Zotero staff are volunteer or full-time employees on a grant or a mix. If Dan is volunteer, then I can understand his comment.
But, if he is employed by a grant, then this comment floors me. What was written in the grant proposals to get funding for this project? We propose to create a useful software tool based on what the lead developer personally thinks the tool should do, and secondarily, it should ideally but not necessarily address the wishes and workflow of its user base?
One reason I suggested a votebox (which is very different conceptually and in practice than any type of forum) is because there are issues with Zotero put forth in threads that have not been engaged with by the developers in any serious way. That seems against the spirit of this type of project.
I'll stop here to see any responses before I comment on the other issues with UserVoice, etc.
But after such a discussion, if I (and the other paid developers) decide not to implement something, then no, everyone doesn't need to just accept that. Someone can write a plugin to implement the feature and distribute that. Someone can create a patch that demonstrates how it actually works and ask us to take a look. Someone can fork Zotero (temporarily or permanently) and distribute the alternative version. If it's mainly an issue of time/resources, someone can offer to find funding for its implementation by us or others. Because Zotero isn't designed by committee. (Or, if it is, it's a very small committee.) Our goal is to produce the best software possible, and that requires our having opinions about how it should work. If someone disagrees with our opinions, they can try to change our minds, do one of the things I listed above, or use something else. I'm not sure why. We don't get grants to then go take votes about what to do with the money. We get grants to implement specific things that we think are worth doing (where the "we" here means, in large part, the humanities scholars that conceived and direct the project). And then we do plenty of other non-grant-funded things that we think are worth doing. Discussions here play a large role in determining exactly what those things are, but ultimately, our job is to make those decisions.
1. Pretty much everyone except Dan and fcheslack* that you'll meet here is a full time researcher and does use Zotero for that. Sean, the project director is a Historian, Simon, the other senior developer is a grad student and MIT. Fbennett, who wrote the CSL processor and maintains the multilingual fork of Zotero is a lawyer. Bdarcus is a geographer. Aurimas works in the life sciences. I'm a political scientist and have my dissertation and multiple articles/chapter written with Zotero. etc. So yes, you're wrong to think that people here don't actively use Zotero for scholarly work.
2. Being a political scientist, I do feel I have a professional obligation to point out that not just isn't votebox/userVoice democracy (I think that's obvious), it's also a poor mechanism to aggregate user demand. a) because by the nature of it you almost entirely get votes _for_ something, but people who dislike e.g. a feature change will pop up only when it's implemented (in other words - how do you know that 500 votes among 500,000 users are a majority?) and b) there is a large literature in political theory and sociology on the advantages of deliberation and deliberative democracy over decision-making based on (majority) voting. It's just not the case that the aggregation of low-cost operations such as casting an online vote are very useful to decide complex questions.
To turn towards something more specific - I think the forum works much better than you seem to think it does. So I'd be interested to know of a couple of issues where you think using votebox would add value. Those issues would have to be feature requests that devs aren't aware have high priority among users or feature changes without significant opposition (since as per above, votebox isn't suitable to distinguish between alternatives).
* I don't actually know what Dan does when he doesn't do Zotero