Prompted by some recent confusion regarding the project node UI (e.g. what a project node looks like on d.o), webchick, hunmonk and myself were just discussing the need for a more coherent plan on redesigning the UI.
Some background issues of interest:
* http://drupal.org/node/165380 -- Make usage statistics visible (see especially comment #75
* http://drupal.org/node/96971 -- Make better use of tabs and subtabs on project nodes
A comprehensive list of other issues related to the project node UI:
* http://drupal.org/node/176776 -- Make release summary table UI look more like update(_status)? report
* http://drupal.org/node/89535 -- add version filter to each project's "view all releases" page
* http://drupal.org/node/89537 -- project-specific releases page needs sorting options
* http://drupal.org/node/49575 -- Allow embedded images in project description
* http://drupal.org/node/101292 -- Reorganize 'support' section of project page, make cleaner place to post support requests
* http://drupal.org/node/64864 -- Reorganize "Link to..." fields
* http://drupal.org/node/75217 -- provide link to installation instructions on project nodes
* http://drupal.org/node/70440 -- Add a link to the CVS RSS feeds.
* http://drupal.org/node/69556 -- move "cvs access" tab into project, make it generic, and add issue maintainers
* http://drupal.org/node/2110 -- Non-'software focused' project management [that's right, a 4-digit node id issue!]
* http://drupal.org/node/49331 -- "Try out a demonstration" is to restrictive
* http://drupal.org/node/32841 -- De-cluttering the project node page
* http://drupal.org/node/32392 -- Issue summary block
* http://drupal.org/node/36199 -- Visual Format
* http://drupal.org/node/15726 -- Include 'maintained by' information on project-module pages
* http://drupal.org/node/16014 -- project/issue/subscribe should be more visible
* http://drupal.org/node/50605 -- Add user ratings for projects
* http://groups.drupal.org/node/5022 -- Possible project metrics (wiki page from drewish's SoC efforts)
* http://drupal.org/node/166631 - Add support for project lifecycle information
* http://drupal.org/node/177376 - Add "QA Test Exists" Field and icon
Given that, I see a few important topics:
- The project node shouldn't always assume software -- we should be more flexible instead of hard-coding everything. Even in the world of software, different sites need different things from the project node, so we should consider how to make this more modular.
- There are a bunch of different ways we present info about project-related stuff: tabs (cvs access), summary table (releases), and sea-o'-links (many other things). Additionally, we don't make any use of blocks for this, but we could certainly consider that. Perhaps even panels and views? We should have a more clear vision for what content should use each of these methods.
- The existing breakdown of "support" vs. "development" doesn't really make sense.
- Many of the (optional) things under "Resources" could probably be automated.
- The "sea of links" is cluttered and wastes a bunch of space (e.g. all the whitespace on the right side of the page)
- We need much better support for screenshots and to make more use of graphics/images where possible.
- There are a lot of things that people want to regularly see which aren't yet visible
So, here are the main things I think should be on the project page:
- release summary table, like the update_status module's UI.
- issue summary table (# of open bugs, features, tasks, support requests, and easy links to view each category, and create issues for each).
- better support for screenshots, especially for themes.
- usage (and ideally, also download) stats
- more coherent CVS info (unifying the "Developers" page and the CVS access tab, etc), perhaps with a summary table of commit activity (e.g. # of commits, most recent commit, # of committers, etc).
- more unified links to support info, FAQ, documentation, forum, etc.
- (maybe) ratings and reviews?
I believe that when someone's visiting a project node, the key things they want to know are:
A) WTF does this thing do? (good description, screenshots, links to documentation)
B) How likely is it to work? (issue and usage metrics, ratings/reviews)
C) How well maintained is it? (issue, CVS + maintainer metrics, ratings/reviews)
D) How do I try it? (releases, install/readme docs)
| Attachment | Size |
|---|---|
| project-module-ui.jpg | 235.85 KB |
| project-module-ui-2.png | 327.79 KB |
| project-module-ui-3.png | 361.63 KB |
Comments
Results from Barcelona...
jpetso, scor, hunmonk, add1sun, and myself (with support from puregin, merlinofchaos, and drumm) sat down on Wednesday afternoon to brainstorm about this. We did it in two hack sessions spread over two days:
Day 1: Identify target audience, what parts of the page we need, what parts we should hide, etc.
Target audiences
In general, there was consensus to simplify and restrict the information shown to the user as much as possible, with links off to supplementary pages with further details.
Part 2: Actually mocking something up.
Our basic goal was to put information that was relevant to each target audience and throw each of those into a block. Yes, a block. This makes these configurable as to what information to show and hide, and we can use OG-like behaviour of hard-coding these blocks to only show on project node pages. Regions can go inside of node.tpl.php to put blocks in the content area itself, if we want.
http://test.logrus.com/project2.html is a mock-up that Earl did a few weeks back, but most of us were too swamped to give it a close enough look-over at that time. Luckily, he needed to borrow a chair and so ended up coming back to our little group and reminding us of that. ;)
We took his starter and kind of went with it.
I've attached a copiously sticky-noted mock, that translates the scribblings we came up with along with a few small changes I came up with as I was doing this. I don't think it's perfect by any means, but it is at least a starting point.
Thanks so much to the folks who co-created this. It was a really fun hack session. :)
Great start, initial feedback
Sweet, nice to see so much interest in this! The mockup looks like a great start. Here are my initial reactions/concerns:
1) The "development" block is a mix of stuff, not all of which is valid on all projects. Even just looking at the d.o use-case, what about projects like the webmasters + infrastructure maintainers? There's no code, CVS stuff, etc. There are no "code maintainers", and the "author" as such, doesn't matter at all. However, issue queue maintainers might be very useful for those projects. Kind seems like "issue queue" maintainers belongs under "Issues", and all the other stuff depends on if the project is CVS-enabled (or, really, versioncontrol-enabled).
2) Having the usage stats buried on a "statistics" page that you only see under the "issues" block seems counter-intuitive.
3) It seems like project maintainers often have trouble figuring out how to add releases, and it appears that in the new plan, they'd have to find all of that via the "Adminster" tab. I know you're still planning to mock that up, but it's not clear that the conditionally appearing "Add new release" link we've currently got is such a problem, e.g. under the "All releases" link in the "Project details" block above.
4) The whole issue of whether or not to show development releases is tricky. a) Not all projects have any official releases :( which is quite a drag, but means we can't always hide them by default, b) some projects don't have dev snapshot releases at all. Also, I know it's not quite ideal, but I really like the update_status UI for this, and firmly believe we should make the project node UI behave more like the available updates report. http://drupal.org/node/176776
5) The screenshot gallery sounds nice, but a) it's not clear how y'all envision screenshots working for themes, where it seems we'd need a screenshot "above the fold" directly on the project node itself, and b) not all projects have screenshots. Moreover, on non-d.o uses of project*, "screenshot" might not make any sense at all for how people want to use projects, so we have to make this configurable/conditional somehow. Again, think of the infrastructure maintainers project as a reasonable use-case.
6) Re: "issue queue maintainers" -- see http://drupal.org/node/69556
7) Not all projects have releases (again, infra/webmasters), so the "Project details" block is going to be pretty sparse for projects without releases. We might want to consider keeping all the release stuff in a totally separate block (provided by project_release.module, of course), so that the design is clean in terms of projects that don't have them (or sites that don't enable them at all).
8) What about a link to the CHANGELOG.txt (if it exists)? Seems like that's a frequently used and useful thing to provide, for projects that have one.
9) I think we should make various kinds of subscription functionality more visible directly on the project node. E.g. email + RSS subscription to the issue queue, email/RSS subscription for releases (new features, see http://drupal.org/node/94137 and http://drupal.org/node/94138). Perhaps views will allow us to solve these problems trivially, but I still think those are things we should make more visible, directly on the main project page (much like the "Group notifications" block from OG).
10) I know it's just a mock-up, and y'all are into the little icons to make the project nodes look more "interesting", but they seem to suck up a lot of space relative to the content, and draw a lot of needless attention to themselves. Once again, my respect for Tufte's outlook on visually displaying data makes me recoil from attempts to make things "look more wow". ;) This, of course, is only a minor critique, but I just wanted to establish my position on the question early, so there's no surprise later when I come down like a ton of bricks on someone's poor unsuspecting patch. ;)
screenshot
re: #5 and the featured screenshot (esp. for themes), the screenshot block at http://test.logrus.com/project2.html certainly makes sense. the mockup above doesn't follow the same d.o/bluebeach block layout relative to the tabs, so i wasn't exactly clear what y'all had in mind. but, something between the example from merlin and the mockup above could work nicely.
We can always just include the title, teaser, and screenshot thumbnail on the theme browsing pages... (a totally separate question for how to define the new views for those). ;)
oh, the rating stuff *is* the screenshot? ;)
hehe ... i think i now interpret this mockup that the star-rating stuff is the example of a screenshot about the module. ;) i thought adding project rating was a top priority, and that you envisioned having a rating system right there for all projects. i was a little confused by having that under a "how it works" section, but reviews and ratings could certainly be considered part of explaining what it is to someone who doesn't know.
anyway, if this is what y'all meant, i think we should add a rating/review block, in addition to the screenshot/demo block. another iteration of the mockup should probably use a screenshot of something less likely to be confused with project node functionality. ;)
thanks,
-derek
bit of a bind
dries talk this morning made it clear that quality/rating of modules was the number 1 most requested feature from drupal.org users, so it seems that we should work this in. the most simple thing (as long as it's approved for d.o) is to use votingapi/fivestar. i think that votingapi allows tags on node voting, so this should enable us to do voting by 'major release', which would translate to one taxo tag per branch. i don't think we need to worry too much about the UI -- iirc, fivestar simply puts the voting widget at the end of the body, which i think is the right place for it.
The question then becomes the question...
So if Fivestar is employed to rate contrib modules, what's the question gonna be? "Is this module cool?" seems like an absolute waste of page space, since its too subjective. "How much do you like this module?" is again useless. "Would you recommend this module to a friend?" is slightly better, but still irrelevant information, since the recommend-ability of a certain module in no way means that it will work for me and my site.
"Have you used this module before?" Now we're starting to get somewhere. That would give us a base from which to discern the more popular modules. "Is this one of your favorite modules?" is again, a valid ranking system. Better yet, how 'bout "Of the modules you use, how good is this contrib?" Now we're getting somewhere!
Senpai
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
responses
1: i believe this is an effective grouping. we can simply not display something in that block if it doesn't apply to the project. i'm not convinced that 'issue queue maintainers' belongs under issues, but maybe. in any case, for this block, don't display what's not relevant, and don't display the block if there's nothing to display.
2: although it's not clear from the mockup, the 'Project details' block already has basic statistical info. i think adding a link to 'more statistics', or whatever we want to call it, is the best way to go here. remember, we're dealing with a lot of information on a project node, everything is arguably important enough to be displayed prominently, so something obviously has to give :)
3: have to disagree here. maybe we can come up with a better name than 'Admin' for the tab, but grouping all of the project maintenance stuff in one area off the main page makes organizational sense, which i think is less confusing. there's one place to find all the tools to do maintenance on the project, and you go there to do it.
4: IMO the update status layout is too much for the available room on the main page. to be clear, we don't hide the development snapshots in the case where there are no official releases, we only hide them if there are official releases. i believe that the other stuff is rightly relegated to a detail page via a mouse click.
5: it seems like we can simply not display the 'Project details' block if releases are not enabled. it might require a bit of tweaking, but most of the stuff in that block is release-specific, so this seems like the way to go.
9: suggestions welcome on how/where these should be implemented on the main page. i agree it would be nice.
10: you're going to get strong resistence to your resistence on this point... ;) to be clear, the icons have nothing to do with making the page look 'interesting' -- they are an excellent tool to assist in visually grouping a giant amount of text information. please take this into consideration when evaluating their usefulness on the page.
Documentation
I think the documentation should be better integrated with the handbooks, and not just a link off to a directory with all modules in it. The "Read documentation" link is also buried IMO.
My $.02
when none exists
It may also be a good idea to point out when no documentation exists. For example, by greying out the link. Documentation is something users look for and it will save them a little time with their search if they can see explicitly that the documentation doesn't exist. Perhaps more importantly, it will act as a reminder that some needs creating. Perhaps we could even be blatant about this:
-
www.alanpritt.com
+1
I likey that!
There's a contrib modules handbook section now.
http://drupal.org/handbook/config/contribmodules contains a page for each module that's worth anything. If your module doesn't have a page in this section yet, WELL!
Senpai
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
rating stuff is a screenshot example
yes derek, this is just an example of a voting module say. I was a bit confused for a sec too. a rating/review block also makes sense in order to grasp the general status of a module, but we didnt integrate it since this type of data is not available yet.
Mockup 2
Explanations:
Project details have been added to the top of the page in the most prominent position. This section shouldn't get too large, so the description should almost always start above the fold. If it were the other way round the description could easily go on too long and hide the project details.
The screenshot is always above the fold, and will only ever take up this much room. This ensures the 'download' block always remains above the fold. The download links are one of the most important parts of the page (usually) so they need to be easily found. The icons help orient users to the relevant download. Other releases are easily found. You could hide the development releases behind javascript, or you could just rely on good design and typography.
I've added an 'also requires...' link, below the specific download link, so users won't have to start installing it before they know a vital module is missing. I can't see how the update_status UI would work in this context, since much of it is based on what the user has installed already.
Reviews (if we add them) are at the bottom of the page. They could theoretically run on for ages, so we don't want anything below them really. However, there is a link in the 'project details' block so that users can easily skip to that section.
Relevant links are also added under 'project details'. Not development links, but anything of particular interest to most users (e.g. documentation, demos, etc)
I've cut out the edit tab. I think any changes a maintainer makes to the project should be in one section. This should make it clearer that this page is for viewing the project details and the other is for making any changes including making new releases.
I've got rid of the icons on the issue section only because I didn't have time to put them in. I think it makes sense to keep them.
I'm not sure it is a good idea to have a link for creating new issues on this page. Ideally we want users to take a look at the issue queue before writing a new one in order to avoid duplicates. Adding a link here will discourage them from doing so.
I agree with dww that basic statistics should all be on the same page. I doubt many people will bother to look at them otherwise. What I've added is probably not adequate, but I think it shows that statistics can fit in quite easily.
I know there are still problems with this mockup, but I've run out of time for today :)
-
www.alanpritt.com
Ooooo!! I *like* this!!
Thanks a lot, this is looking really good!
+1 for links like "Live demo" and "demo video", as well as your suggestion about "if it doesn't exist, point that out rather than hiding it" from above. Excellent.
+1 for "also requires"... that's great information to have right at the beginning.
+1 for the basic statistics in the list of types of issues. I didn't think of laying them out that way, but it totally makes sense.
-1 for the loss of a "Search issues" link -- we don't need to necessarily have it on all types (that was probably overly cluttered), but it would be nice to have it there somewhere. Or even a search box itself that points to the issue search! But either way, this needs to be more visible so that people don't keep posting duplicate issues.
I'm kind of on the fence about the loss of the "Submit" links on the various types of issues. I can see where you're coming from, but having them there eliminates a bunch of steps (Create content, issue, select project, Next, choose type...) Maybe the answer is to make the "Submit issue" link more prevalent on the "list of issues" view.
Cutting out the edit link is a nice idea for simplification, but unfortunately it's sort of "built in" to nodes. However, it'd be very easy to discuss (probably in another post) how to organize the various sub-pages in the edit page to make this more clear; maybe the edit tab is just basically for the title and description and everything else gets moved under "Manage"?
Some questions:
a) Where does "Support" link to?
...
That makes a lot of sense!
Yes, and this is one aspect I wasn't happy with since the above doesn't make it obvious how to submit issues. This certainly needs more thought.
hmm, I don't tend to think in terms of what is possible (I just assume most things are)! But, yeah, probably something to discuss in another thread.
Should there be more questions here?
Anyway, this was the victim of an unfinished thought. I was trying to get my head around the idea of how support works. I was thinking it doesn't quite feel like an issue in the same way as a bug does, so I was wondering if it should be presented differently. For instance, is it more likely that a beginner would be posting support queries and not other issues? If so, should we present this process differently? However, this is probably more a consideration of the issue queue anyway.
-
www.alanpritt.com
A couple other differences based on worldfallz's input below...
a) We should move the developer stuff into another block, so it isn't coupled with the issues stuff, which may be used outside of a software development context.
b) The categories should probably be part of the node itself, not in the project details block, for the same reason.
I'm a refactored human
I'm a refactored human factors/usability engineer so please forgive me for obsessing a bit on the ui-- but i keep having the nagging thought that there are a certain subset of things common to all use cases that should appear on the project page. I made a quick and dirty mockup on my drupal sandbox--- take a look and see what you think.
There's gotta be a cool way for initiating a search
Webchick sez:
What if there were a way to link directly to a drupal search that targeted the issues for that particular module, but allowed users to type in a keyword or two before it whisked them away from the project node to the list of active issues? Can we do that with a jQuery-toggled field?
(I'm thinking of a cool way to get the user to the Submit A New Issue without allowing them to actually submit an issue prior to a keyword search)
Senpai
Joel Farris | my 'certified to rock' score
Transparatech
http://transparatech.com
619.717.2805
re: "also requires"
yes, that'd be very slick. some technical problems to throw into the mix (some of which have UI implications):
1) the .info files for the modules include dependencies which we'd have to parse. the format of the dependencies line changed from 5.x to 6.x, so our parser would have to understand both.
2) parsing .info files DOES NOT belong in project.module or project_release.module. ;) This is utterly-specific to d.o (or other sites hosting drupal modules), so, we need to think carefully about where this code should live and how it will cleanly tie in to project*.
3) the dependencies in the .info files point to specific modules, like views_ui.module depends on views.module. However, from the project UI perspective, we only care about cross-project dependencies. As in, og.module depends on views.module, and you have to download them separately. The .info file just says what module(s) are required, not what projects they belong to. So, it seems like we'd have to parse all the .info files and keep track of which project each .info file belonged to in a giant DB table. When we see a dependency for a given module inside a project, we'd have look up what project that dependent module belongs to, and only print something if it's in a different project. Furthermore, we should print a link to the other project (by project name, not module name), and only include a single link to each other project that this one depends on. E.g. some views bonus back module might depend on both views.module and views_ui.module, but we should only have a single link to the views project in this part of the views bonus pack project page.
All of this is further complicated by the fact that a given project might include multiple modules, each one that has different dependencies! Again, think views bonus pack. YUCK.
That said, this would be a great usability enhancement, and we're all smart enough to solve these problems. But, I needed to point out that this particular nice feature is actually a huge tangle of complication, and folks should seriously consider how hard it's going to be to get it to actually work right before they get too excited about having it on d.o. ;)
Much as I hate relying on
Much as I hate relying on the human being for stuff-- a lot of the module maintainers put this info on the project page now (and usually in the readme as well). Much more reliably than screenshots or other info-- at least it seems so to me.
The first step could be to just designate a specific place for the info, make it a required field, give it a link in the proper spots/blocks, and simply rely on the author/maintainer to type it in manually. Then step back and assess whether or not it works before going through all the effort to code it when there's so much stuff that needs coding that can't be done any other way.
punt to the human sounds totally reasonable for phase 0
Yeah, punting to the human wouldn't be the end of the world for this, at least not for phase 0. It still seems rather d.o-specific, so I don't think I'd want to hard-code this in to project.module itself. I think it should probably go in the forthcoming drupalorg.module. ;) However, I'm open to suggestions...
Project dependencies aren't an insane concept in general, though they might take much different forms than software that requires other packages/libraries/etc. But, if you left the field blank, it just wouldn't show up anywhere, so if dependencies/requirements don't make sense for your project, you could choose not to fill anything in. It's not clear to me exactly what the UI for the project maintainers should be (a simple text area?) and how that gets displayed on the project node (it's own block?)... It'd be nice to enforce some consistency in the d.o case, but that might make it too rigid for non-d.o sites. :( Any specific suggestions would be welcome.
The way I see the input UI
The way I see the input UI for this implementation would be very much like the way status customization is handled-- an open ended list in a table format. It could be as simple as 2 fields--- description and URL. Or perhaps 3 fields--- URL address, URL text, and description. That would maintain the most flexibility for vcs and non-vcs systems. In my use case, that would work perfectly. The presentation could be handled via a block-- a simple unordered list would be sufficient I think (sorta like the way "My groups" block displays). I have on my Todo list implementing my category customization hack this way in order to turn it from hack to a "contributable" patch so that would make 3 things function that way (if patch is accepted)-- so that would make for nice consistency.
OT: issue for category customization
FYI: http://drupal.org/node/115553 is where you should post your efforts at customizing the categories. Thanks!
Wow! Something like these
Wow! Something like these layouts would be phenomenal. Awesome work so far.
~~~
StephTheGeek.com | Themer for CivicActions
~~~
{ TopNotchThemes | Fusion Drupal Themes }
As someone using the project
As someone using the project / issue tracker modules in a non-software way, I'm very curious how much of this stuff is going to be hard coded. Even though the #1 comment on the first post in this thread points to the issue of not keeping these modules so software-centric, most of all the comments, suggestions, functionality, etc. is very much centered on a software centric use case. And being that it's most geared toward it's use as a vcs frontend for d.o.,that makes perfect sense.
I guess my growing concern stems from the fact that the only hacking I had to do to change the software centric nature of the current modules is change the categories and priorities-- everything else could be changed from the UI. And it seems as if a lot of this new usage may be defacto and therefore require much hacking to adapt to a non-software use case.
I basically use it as an issue tracking mechanism, and use project to categorize areas of issues-- i have one for the entire web site I use as an administrator, one for each OG group to track their internal issues/action items, and I have some PMs that use it as a basic issue tracking mechanism for a multitude of different types of projects that don't warrant the use of our full service clarity PM system. I'd hate to lose this functionality.
It may be that these modules, by virtue of their necessity and use on d.o., become unsuitable for non-software centric use cases. Thats a perfectly valid decision also, but then it will expose a need for a non-vcs issue tracking module because constant hacking in order to keep pace is not a viable solution for a production site. And although I've investigated other modules for this, I just found this to be the best one.
Currently, the only 3 things that need to be changed for using these modules in a non-software centric use case are:
1. categories - have to manually hacked to change them
2. hard coded software centric links on the summary page - related to categories, also can be hacked or simply hidden with CSS
3. priorities - easily hacked/changed
All 3 are pretty easy to address with fairly simple hacks, though I detest hacking modules.
However, from what I see above, almost all of the very beautifully specified new and improved project home page will have to be hacked / hidden / overridden if not customizable-- the "How it Works", "Development", and "Project Details" blocks will be largely not applicable. Ratings will be not applicable. And the icons, if not selectable, will also cause a problem. The "don't hide it if it's not applicable" approach will leave a lot of links that will inappropriate for non-software usage. And hiding blocks that don't apply doesn't leave much left to display for non-software use cases. Even some of the headings will be not applicable (ie "Issues and Development", "Maintainers", "Developer Links", etc.)
I don't mean to sound negative-- I think this is really really great work-- for a software project management module. As a drupal admin, it will make finding and using modules infinitely easier.
As a non software user of the project / issues modules though, I'm concerned about the possibility of continued use of these modules in a non-software environment.
Am I the only one using these modules this way? Are the needs of d.o., which are the most important driver for these modules, causing them to be inextricably linked to a vcs use case? We don't want to sacrifice functionality necessary and beneficial for d.o. for a non vcs use case-- is it perhaps time for a fork for a non vcs use case?
I'm too new to drupal to be able to intelligently answer these questions-- what do ya'll think? Any other non-software users of these modules out there want to speak up?
Also, I'm happy to volunteer my services in whatever way is most helpful.
This is valuable feedback...
I wasn't sure in what ways Project module and friends could be used without being a software repository. That totally makes sense.
Looking at the UI proposal as it currently stands though, I don't think there's much to worry about:
- The five-star rating and review stuff is basically Fivestar module and comments, and has nothing to do with Project. If you don't need it on your installation, you don't need to add it.
- #2 of bvlah blah comes from project usage module. Again, if it's not relevant, don't enable it.
- The download block will come out of project release module. Don't enable that module, and it won't show up.
- All of these things -- Screenshots, Download, Project Details, Issues and Developemnt, and Subscribe -- are going to be blocks. These can be easily disabled using the block admin interface. This leaves you with just a title and body on a normal Project node. So if anything, this should require less hacking for you to do to use it in a non-software context.
That would be great-- us
That would be great-- us non-vcs users could always just write our own blocks / views to display what's important for our use cases.
My only other comment would be that the "Project Details" and "Issues and Development" blocks seem pretty basic functionality and should be as generic as possible (ie. name the "Issues and Development" block "Issue Details" and make links there based on categories/components/priorities etc or customizable-- instead of hard coding the label for the link use 2 fields-- one for the label and one for the link itself) if it doesn't adversely affect their usage/functionality for d.o.
Need any code for this?
I have a Review as Node - Fivestar module I've written. You can view it in action at unitorganizer.com/drupal5. It basically allows users to create a Review node and attach it to a piece of content.
username: esykes
password: infinity8
I don't know if you have all of the code written already or not, but I am willing to volunteer my module if you have not (I wasn't sure if your UI mock-ups were coded yet or not...).
Dave
Yes, we need code, but...
Yes, we definitely need volunteers for all of this. None of it is written. However, specifically regarding user ratings/reviews, you must read:
http://groups.drupal.org/node/7191
Thanks,
-Derek
re: project metrics
Yeah I just read that article and the one it's linked to. My rating system definitely relies on user reviews, which makes it less than useful. I guess I'm more of an optimist, but a bit of pragmatism is necessary here. Having a rating system that is harder to 'spoof' makes a lot of sense.
casetracker?
have you thought about looking into the casetracker module for your needs?
this is not meant to disuade the point you brought up, but rather to offer another possible solution to your concerns.
Yep, loaded it up and
Yep, loaded it up and evaluated it side-by-side with project / issue modules before making a decision.
I even had some users test drive both and give me their feedback. I can't seem to articulate why, but project / issue just "fit" better--- even with the hacking I had to do. Once I made the 3 changes I describe above, it was perfect. Case tracker seemed like it would require more tweaking, but honestly, I didn't really try. That's nothing against the case tracker module, it just didn't fit our use for some reason. Who knows, maybe project / issue was more comfortable for me simply because of it's use on d.o.
Another user's opinion....
I'd actually like to use them in a software / version control system associated way, but I'm also sure that I would like to be able to modify the way some things are presented to my users. Would it be very difficult to handle the rendering of output through .tpl.php files, as for other modules in D6? Finding a good solution for d.o. is great, but it still might not be ideal in a different context. Thus, being able to theme things easily and without hacking would be great IMHO.
Just a thought,
Christian.
I support worldfallz's comments 100%
As I've pointed out over-and-over again, even d.o itself makes use of projects that have nothing to do with software, revision control and releases (the webmasters and infrastructure issue queues, for example). I've used project* on sites just as an issue tracker for problems with that particular website. Again, nothing to do with revision control and releases.
I have absolutely no intention of committing any code that makes project* assume software and revision control. The more we can keep it generally useful in a variety of cases, the more it will be used (well, duh). The more users we have, the more folks will have an interest in porting it all, helping to improve it, testing patches, etc. Long-term, the health and well-being of project* (and therefore d.o itself) depends on getting more people to help, and that means making/keeping it useful for sites other than d.o.
In terms of how you can be most helpful:
a) keep doing what you're doing here -- raising the points about non-vcs-centric uses (since apparently, if someone other than me makes them, folks will listen instead of thinking "that crazy dww, he's always yammering about that stuff..."). ;)
b) give specific feedback on existing mockups, or make new mockups to flesh out other areas of the UI that need help. for example, parts of the admin UI to customize these project node enhancements (if it's not all just controlled via admin/build/blocks), etc.
c) read http://groups.drupal.org/node/3686 for a more general list of how to help with project* -- of course your skills are specifically in the UI world, but those could apply to a bunch of the things I wrote up at #3686.
Thanks!
-Derek
how else to help... (a little off topic)
oh, and i forgot to mention:
d) find the issues already in the project* issue queues on d.o about the things you had to hack/customize to make project* not too software-centric. there might be duplicates, so find the oldest one for each topic and mark the others dupes with a link to the oldest. then, "bump" the issue by replying to it and offering your suggestions on how to make the currently-hard-coded thing more general. ideally, attach a patch that makes the given functionality general purpose enough to continue to work for d.o and also for your non-software site. in the rare case that an issue doesn't already exist for something like this, please create one (again, ideally with a patch). ;) if a patch is out of league, at least an explaination of how you think the functionality could work, with mockups of any parts of the UI you think are relevent.
i know this isn't directly tied to the project UI mockups we're discussing here, but since it all came up, i wanted to help channel your offers for help in the most productive directions. ;)
thanks,
-derek
Excellent feedback-- for
Excellent feedback-- for some reason I hadn't stumbled across the links you provided. Those are exactly the kind of concrete suggestions I was looking for. I'll dig right in and see what I can contribute. Thanks for the reply.
Project usage stats -- need progress
http://drupal.org/node/165380 is a high priority for me. That patch is only being held up while we decide what paths the usage pages should live at, and how exactly they're going to be displayed on the project node. It seems like all the mockups in here are moving away from using tabs for anything, and instead seem to like the idea of pointing to separate pages for various things that require more detail and which we can't cram into the project node itself. Is that the case?
I certainly appreciate folks stepping back and dreaming about mockups and how it all should be, that's great. However, I'd really love it if some of the folks in this thread could take a look at #165380 (in particular, comment 75), and leave their thoughts there so that drewish and I can at least make progress on that in a way that's going to integrate nicely with whatever changes come out of these design efforts. I'd really like to avoid link rot for the usage pages, which is why I started this thread in the first place.
Thanks!
...
I generally find tabs are a little ambiguous until you've learnt what they do by clicking. If you instead put them within the context of the page, the destination is obvious. It's also an obvious place to find them. You would not be looking at the summary metrics and then think to yourself 'hmm, I wonder if there are more detailed stats somewhere. Maybe there is a tab somewhere'. If you put the link in context, you just stumble upon it at the right moment.
Done.
-
www.alanpritt.com
Mockup 3
A few notes on the changes since #comment-17826:
If there is no documentation it gets greyed out. See #comment-17856.
Moved categories out of the project details block and into the main node. Also divided issues and development into two blocks to make it more versatile for different types of projects. See #comment-18004
Added age of oldest issue as suggested in #comment-18103. This seems like a nice idea to bring attention to outdated issues that might want cleaning up. Other suggestions from this comment are basically already included. It would probably be worth discussing what other numbers we want to report regarding the issue queue activity. But currently I've included totals, active and unanswered subdivided into bugs, support, tasks, feature requests and all.
I've added a search box to the issue block (see #comment-17918). I've also added a note to explain where users can submit issues. But I don't want to include the direct link because users should always either browse or search. There are no cases where a brief look at the queue isn't warranted first. However, the current issue queue pages need a little love in order to make the 'create new issue' link more obvious.
The layout is specific to Drupal.org but of course everything can be reordered and re-themed for different projects.
-
www.alanpritt.com
Warning Text
I would suggest adding a small blurb of warning text in the development releases box, letting users know that they could be downloading potentially unstable code, and should stick to stable releases if possible. Something like:
It sounds scary, but hey, better than someone getting screwed.
Admin UI step #1
Howdy, folks interested in the project UI. This is a little OT from most of what we're talking about here, but I wanted to draw everyone's attention to http://drupal.org/node/203313#comment-668080 and the mockups there. This is about the project admin UI (for d.o project maintainers) to specify supported and recommended branches for each version of core their project supports. Please see the issue and reply there if you've got any input, thoughts, alternate proposals, etc. Thanks!