Three weeks ago, I launched a Drupal.org survey, the objective of which was to get feedback on the Drupal.org website and to prioritize the work we should put into improving it. The results of this survey are below.
Target audience
In total, 375 people responded to the survey. The first graph shows who responded to the survey and how often they visit Drupal.org. It defines Drupal.org's target audience. As can be seen, most Drupal.org visitors are Drupal administrators that visit this site frequently.
Purpose of visit
When asked where they spent most of their time, they responded as follows:
Most people spend their time in the forums looking for answers/support. Thus, most people would benefit from forum improvements though, as we'll see later, this is not the problem area. Surprisingly (at least to me), 17% of the people spent most of their time in the bug/patch/issue trackers.
Drupal.org development focus
Next, we asked the participants to agree or disagree with a number of statements using a Likert scale. The statements and the accumulated result, are given below.
The full statements:
- We should improve the structure/organization of the forums.
- In the forums, we should show who is who, and who did what.
- The support mailing list should be eliminated in favor of the support forums.
- On the download pages, it should be possible to navigate projects by category.
- It should be possible to rate projects, and to browse projects by their rating.
- We should improve drupal.org's main navigation structure.
- We should improve the navigation structure of the Drupal handbooks.
- We should improve the quality of the documentation in the Drupal handbooks.
- We should extend the amount of documentation in the Drupal handbooks.
- We should improve the search functionality at drupal.org.
- We should improve the "recent posts" page so posts can be filtered by type, category, etc.
- We should provide e-mail notifications for new forum topics or replies.
- We should provide RSS notifications for new forum topics or replies.
- I would like to flag, bookmark or tag content/pages that interest me.
Overall experience
Last but not least, we polled the user for its overall experience. Turns out that most people do appreciate the work we put into maintaining Drupal.org and that most people are happy with the site. 58% of the participants rated their overall experience as 'good' and 29% as 'very good'.
Nonetheless, there is room for improvement and we're committed to bettering your Drupal.org experience. We'll start by implementing the prioritized TODO list below.
TODO list
- Improve the Drupal.org search. This requires search module improvements. Fortunately, these improvements are well on their way. More about these later.
- Make it possible to browse projects by category. Requires project module inprovements. The grunt work has been taken care of by Nedjo but we're not there yet. More code needs to be written, and ultimately, all projects need to be categorized using card sorting. We talked to OpenUsability, and they are working on a card sorting tool that we could use.
- Make it possible to rate projects. Requires project module improvements. We have concrete ideas as how to approach this once the first two items are in place. In particular, we want to categorize projects by (i) popularity (number of downloads, or number of installations) and by (ii) rating. The former rating is computed automatically, the latter is the result of a manual rating system where each user gets to cast a vote.
- For returning visitors (and the vast majority of our visitors turn out to be returning visitors), it's important that they can easily track new or relevant content, as well as continue where they left off last time. Therefore, we hope to improve the "recent posts" page (tracker module) as well investigate how we can implement e-mail and RSS subscriptions. Unless some people step forward to help, it will probably take a couple months before we get to this last item.
(Note: we have a couple more survey results but we'll talk about this in a separate post.)
Comments
Concerning todo items..
Concerning 3rd statement:
Instead of having several "blocks" bfor navigating through downloads (or anything with ratings) one could compute a general popularity index from a formula with both number of downloads/installations and manual rating. Thus ratings of modules not upgraded over time, or deprecated modules, would fall over time. Manual rating is not something that should be fixed as it is a view of the moment, and number of installations and manual rating is sort of different perspectives for the same thing.
Concerning 4th statement:
Actually instead of "New forum topics" block: What about listing both new topics, and new replies, only expand listing to include both topic title and reply title when it's a reply that is listed ?
The same goes for the tracker page (both node and comments titles) only it should also be categorized by the sections: projects, handbook, forum, etc.
By the way, great work with the survey !
Todo
Very nice. Thanks Dries. I guess we are all quite happy so far ;-)
One thing that I would like to see is the concept of weight extended to Node type. Meaning I want book pages to have more weight than Pages which have more weight than images.
This way I can have book pages show up first when browsing content or when searching which is very important to me.
Another useful consideration (to me) is the choice of having the cache outside the database. I am not sure if this is doable at this point, but if I site gets under heavy load I guess this could proof worthwile.
Andre
-------------------------------------------------
http://www.opentravelinfo.com
http://www.aguntherphotography.com
With the Forums
I think surveys like this are great. When it comes to the forums I would like to see my posts stand out more maybe the post has a different border or background colour or my user name is a different colour any thing that makes it stand out more. This way in long threads it is easier to follow the discussions you took part in.
Thanks.
Pictures
This site could just allow uploads of use pictures. That's what they are designed for.
--
Get better help from Drupal's forums and read this.
mmmm, yeah but....
I certanly don't want to see my face alll over drupal.org ;) or a lot of pictures that will slow down my website.
I think that the color idear in the parent post is pretty good.
+1 for that idear :)
Alexandre Racine
www.gardienvirtuel.com Sécurité informatique conformité, consultation et plus
www.salsamontreal.com Salsa, évènements, La référence salsa à Montréal
Kind of tough with tens of thousands of users
You can easily limit the size of the pictures. And I don't see how different colors will do anything to distinguish between so many users. Plus, it will just look garish.
And if you dont' want your face to appear, use a more anonymous image.
--
Get better help from Drupal's forums and read this.
Colors would work
...if you are trying to emphasize only your posts. You being whoever is logged in.
Defiantly only your posts
Defiantly only your posts if you are logged in. if you are not logged then things look the same as they are now.
I got to agree
I got to agree. If I had the option I would probably not upload a pic or Avatar. I dont on other sites. If you look at what a post is made up of.
Head (Title, username and user account link and date)
Post
Signature
What if the head of your posts has different background color. Maybe a light gray. The way I see it this could be done in the theme and would not require any php.
Dont forget drupal.org has a lot of users that would be a lot of disk space just for user pictures. This would also add to backup size and increase site overheads.
actually...
Actually the idear is to change only the color of your post, not others, only if you are log in also :)
Alexandre Racine
www.gardienvirtuel.com Sécurité informatique, conformité, consultation, etc
www.salsamontreal.com La référence salsa à Montréal
Provide options to expand the scope
While agree, I don't wouldn't support the use of photo's on a forum under my control, I do however support the concept.
The reason I support the concept is that it's better to be "inclusive" of all ideas rather than exclusive (based on one's own preferences).
So.. Cater for the idea and allow administrators to "Turn it ON or OFF" as they see fit.
Russ
---
Russ @ Firewize
Concerning topic #4, I am
Concerning topic #4, I am 80% into a module that will do just that and a lot more. I intend to post for an alpha test of the module sometime this week for comments and help with direction.
Just to tease a little, I call the module 'views' and it is basically a customizable query generator that should let administrators customize how lists and tables of nodes are presented, especially in terms of how they are sorted and filtered, and also allow module developers to expose node extensions to the module so that it can take advantage of their features.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Core?
This is something we've been talking about for a while and that we like to have available in core. Rather than implementing this as a module, it might be worth creating patches for core (against node.module, tracker.module, etc). Take a look at http://drupal.org/node/22183#comment-28935.
Core may be better
It's difficult for me to say, given what I have set up. At the time I started it I didn't think it'd be wise to directly try to write stuff for core, but instead to publish a module in the hopes that it'd be adopted into core instead.
At the moment it's pretty firmly a module, and I'll drop it into alpha this way as soon as I finish the last piece. It's a little bit more complicated than what you suggested in that comment, which is both good and bad. It can do what that comment wants, mind you, it just takes a little more setup than a URI.
That said, at the moment adopting the module into core and patching other cores to use its views might be the way to go. I'll get this into an open alpha soon, so we can get some commentary on it.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Ok, I've got the alpha
Ok, I've got the alpha ready; I posted about it here so as not to take this post over with discussion on it.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
and then into my sandbox
where you can find a (name collision...) urlfilter module which begins to implement Dries' fine idea.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
Bravo on 4 to dos
I completely agree with the 4 To Do items.
Drupal.org is sure to go from good -> great.
dado
http://schtickdisc.org
Downloads page
There are alot of modules and themes, all presented on the same page sorted by name. It is really difficult to follow the new or updated items.
I think it would be great if an option to sort the display using "date of submission" and "last updated" and present a "new submissions" view for the last x days..
and, as said before, adding categories and rating can be really helpful too.
Well done, Dries.
Well done, Dries.
The better data the Drupal project leaders can gather on the community and the faster we can all iterate improvements based on that feedback, the stronger the product and community will be.
More data analysis
Well, it is a great thing to have these surverys and this one was well done, but about the data analys, I think a) we can get more information out of it and b) we cannot come to conclussions that easily. And let's remember d) Results are always biased by the methodology.
At first sight of the results, some of my objections/suggestions are these:
When considering who answered the survey, we have only three profiles: Administrators, contributors and potential users. If I remember right, to participate in the survey -I did :-) - you had to be registered. So, what happens with anonymous users? Aren´t they an important amount of drupal.org's users? Don't you think that could be maybe too many 'potential users' that don't take their time to register?
Then we are assuming that each profile answered the survey in the same proportion. What if i.e. site admins are much more prone to participate than, let's say, contributors, or maybe it's the opposite. That means we cannot say which is the real percentage of administrators or contributors that visit drupal.org looking at the data we have.
Also, it seems like we are somehow identifying 'target audience' with 'actual audience'. But the target audicence is not maybe what we have, it is more a question we have to ask to ourselves: Who is our target audience?
One thing I'd like to know -and maybe the information is already there only waiting to be extracted- is how the results relate to the user's profile. I mean, what do administrators want and what do contributors want? Do they want the same? And if they don't, does it make sense to have the same site for them all? Or maybe it would make sense to have some subsite only for support forums and another one for technical discussions?
If you look at it this way, it shouldn't be a big surprise that, if 19% of the people who participated in the survey are contributors -which, as explained above, doesn't mean 19% of drupal.org users are contributors-, then 17% of the people spend their time at the issue tracker.
My general idea is that these surveys are ok, but bit too biased by the 'who likes/has time to participate in surveys and who doesn't'. I am sure that much more useful data could be gathered from real usage of the site -like which % or regular users have actually submitted a patch or post in the issue tracker?-.
So I'd say: let's take the survey as what it is, a survey, let's take the results into consideration when making decissions about future developments, but please let's not make important decissions based solely on these results.
https://reyero.net
Think about it...
Think about it...
The purpose of the survey was clearly stated
In my opinion, Drupal.org is a site for the Drupal community and it's participants (others probably have differing opinions)
Anonymous users to me means not bothering to participate. Keep in mind that you must be a registered user on Drupal.org to post questions and answers in the Drupal.org forums. This was how to improve Drupal.org. If you arn't a member of the community, then in this paticular case, the survey isn't for you.
That the largest participants of the survey identify themselves as site administrators is not surprising. That is really what it takes to setup and maintain a Drupal install. End users in general, do not visit Drupal.org. Potential users will become site administrators if they choose to use Drupal (or pay someone to be one for them).
I think this was an excellent start to narrow things down to come up with a list of things to actually do.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Not the point
Ok -agree with some, disagree with others-, but that's not my point.
These things about anonymous users and admins, etc... were just examples.
The thing is that, while the objective of the survey is well stated, the conclussions go way too far interpreting the results of the survey.
These kind of surveys may be very very misleading when you make such a simple analysis and you trust it blindly.
https://reyero.net
Let's be realistic...
and not try to overcomplicate things. We're not scientists trying to make objective observations about reality here. Nor do we have tens of thousands of dollars to hire pollsters to determine the best way to collect data from users. We want to make some basic improvements to the site using our best judgement on where to expend very limited resources.
They survey may not be absolutely definitive, but it's certainly better than no survey at all.
"The perfect is the enemy of the good."
--
Get better help from Drupal's forums and read this.
We can do better
> They survey may not be absolutely definitive, but it's certainly better than no survey at all
The survey can be useful if you give the results their fair value. But we've gone bit too far with the conclussions, and that's certainly worse than no survey at all.
Just as an example:
> As can be seen, most Drupal.org visitors are Drupal administrators that visit this site frequently
This single one shows a very important misunderstanding on how to interpret survey results. From the same data I could say too 'Drupal administrators are usually registered users who visit the site frequently and are willing to take surveys' which would be also wrong.
Come on, we can do better than that.
https://reyero.net
Eggagerating?
But we've gone bit too far with the conclussions, and that's certainly worse than no survey at all.
Come on, we can do better than that.
Clearly, you're eggagerating.
Sure, potential Drupal users might not feel inclined to participate in the survey, and maybe that sentence should be rephrased to read: "As can be seen, most Drupal.org survey participants are ...", but saying it's worse than no survey at all, and that we can do better than that, is rather lame.
The reason I asked several questions about their involvement with Drupal, is exactly that, to put the survey results in the right context and to be able to interpret the results accordingly.
Rather than talking about improvements or volunteering to help, people are complaining about the survey methodology? Let's give this survey the right weight; all we're trying to do is prioritize a TODO list.
Yes, Dries, I am, but...
I admit I am exaggerating :-)
The survey was ok, and the results are interesting and nicely presented. That's true.
I really just wanted to call the attention over the fact that we started with a survey that shows what some people -registered users, frequent visitors- think, and we end up extrapolating the results for all drupal.org users..
> Rather than talking about improvements or volunteering to help, people are complaining about the survey methodology?
I just thought that pointing that out was helping too. Never mind.
> Let's give this survey the right weight; all we're trying to do is prioritize a TODO list.
That's what I mean. I just felt, reading the post and the thread, that some points were overweighted...
And I still insist -rephrasing- that no conclussion is better than wrong conclussions :-/
Cheers!
https://reyero.net
The info is useful
So maybe the conclusions are underdetermined by the data, but I agree with Dries that you exaggerate in saying that we are worse off than without.
The survey gives a general idea of directions to be taken.
To construct a survey that completely eliminates all but one interpretation is nearly impossible.
Best regards,
Lennart
Best regards,
Lennart
A good start, but more good data is there to be found
I've got to agree with Jose's post above. He makes some excellent points that should not be ignored. The objective of the survey, as helpfully restated by sepeck, is also useful but pretty broad. For my money, it all depends on the what drupal.org is there to do.
I would say it is trying to do a number of different things for different audiences. The way the data has been interpreted favours very much the idea of making the site better for those who already closely engaged with Drupal - site admins and developers/contributors. Of course these are vitally important audiences, and need to be well looked after.
But surely the most important audience as far as the growth and long term success of Drupal is concerned is the potential users and new users - the site admins and contributors of the future. A few months ago I was a casual site visitor, trying to find out more about Drupal and whether it was right tool for me. Drupal.org was not very helpful in enabling me to make that decision - other sites were more useful. I have to say that neither is drupal.org much good at enabling me to learn how to make the best of Drupal, and speed up the development of my sites - as a newbie site admin. People like me are the evangelists and key supporters of the future, and yet I would say we are not well served, and the survey results, as they appear to be interpreted - do nothing to instil confidence that this will change.
Essentially, if the hard core Drupal fans want it to become the success it probably deserves to be, you've got to enable that success to happen, by making Drupal an easier product to learn and use. And drupal.org is clearly central to that goal.
As Jose suggests, the answer might be in having more than one site. Research certainly needs to be done into those potential users and unregistered site visitors to learn more about them. If Drupal were a commercial operation, those casual site visitors that don't register would represent a big chunk of lost revenue.
As for the site admins and contributors, why not do some analysis of the results to see how the responses compare and contrast between these two user groups. It may be that they have totally separate needs, but the analysis to date appears to simply group them into a single block. As a would-be site admin myself, I would suggest that my needs, and those of an active developer/contributor are pretty distinct.
In summary, this research exercise is a great start, but as Jose suggests, don't rely on it alone, do some more analysis, and then ask some awkward questions.
Here's a question:
Here's a question:
Survey respondants were asked if they're devs or admins or potential users. What do the rest of the graphs look like if you look at ONLY those respondants who marked themselves as potential users?
What exactly will come out of the survey?
Okay, so the survey is done. What will be the outcome? If you do a search for the keywords in each question and study the threads then you get the same information only with a bit better context. The survey seems to only confirm what is already known.
I say this because this survey will not:
It is totally unlike the usability survey where the information is used to guide an already ongoing development. In the case of Drupal.org most threads concerning it end in a need for warm bodies.
I am not sure if I am expressing myself correctly but the content and the answers to the survey leave me with a feeling of emptiness. Maybe someone can explain to me how it helps anything?
You missing the Point
I think this survey will do just that. This survey is to prioritize development and improvements to drupal.org. These improvements are meant to make the site more user friendly and help users help them selves when it comes to support. If users are able to find answers for them selves more easily then developers will have more time to do what they do best.
As I said can someone
As I said can someone explain to me just how? How is this survey going to cause change where the forum threads and posts that prompted the survey did not.
In the case of prioritising. I think it is difficult to reprioritise resources that don't exist. Developers volunteer or do pretty much what they want or feel comfortable with. They are doing this now and as a result there is a need.
Is there something I missing? Because I can't see how this is going to attract more developers or influence those that are already busy with other projects.
I guess I am looking for a free education on the logic being used here.
The first difference is that
The first difference is that the few loud posts were not focused nor did they actually agree on what specifically was the most important path paticularly when not one of the people involved in complaining offered to help get work done.
The second difference is who the survey was done by. There is a difference between random people offering random complaints and the project leader looking for better feedback.
-sp
---------
Test site, always start with a test site.
Drupal Best Practices Guide -|- Black Mountain
-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide
Yes, there is something
Yes, there is something you're missing. The number of core Drupal developers is not 0.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
Resources
It's not the survey's goal to attract more developers, or to free developer resources. It's about focusing the efforts needed to improve drupal.org.
There are several people (including myself) that are committed to improve drupal.org. Clearly there are some resources, otherwise drupal.org wouldn't be humming along.
I guess it is a watch and
I guess it is a watch and learn type thing then. So I will take a sip of coffee, relax and watch.
Or you can help
Or you can help. Either by working on the items on the TOOD list (if you don't know where to start), or by tackling something that you enjoy doing more. After all, it's about having fun. :)
being able to focus is the goal!
As Dries points out, the main goal of the summary is to be able to focus ourselves better.
Take for example Ruby on Rails. It has a VERY narrow and VERY clear focus. That way they are able to communicate much better, write very good tutorials and develop their code in a certain direction.
Drupal, as it is now, tries to cater all, and while doing that fails to do that very well, because it does it all. A lot of good information is swamped by bad information. A lot of support gets buried in discussions about why drupal should have Foo or Bar. And even more heated threads appear about whether *drupal* should care about point-and-clickety-users-w-o-a-clue, or whether Bryghts/Civicspaces et al should do that.
So, I think Dries is very correct to say that, eventhough the result might be biased, eventhough the result could take into account, the fact not all people were as willing to complete a survey, we can still see clearly where there is work to be done, and where we can let it all rest for a while.
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
would anyone be interested in the bookmarks module
would anyone be interested in getting the bookmarks.module activated for drupal.org?
I've found a lot of useful information on drupal, and the only way I can get back to it is either by using bookmarks on my computer or remembering what I searched for when I landed on a useful page.
I know the Drupal Todo list is already quite packed, but the bookmark module is already there.. I'm guessing it just needs to be activated.
It would certainly make it:
Apologies if my two bits are a little annoying..
Gautam Chandna
--
http://www.ahste.com
i like the idea! it would be
i like the idea!
it would be really usefull
+100 on bookmarks :)
I use the bookmarks module on my own site to bookmark admin pages I hit a lot (like logs). Having that on drupal.org would be awesome!
Michelle
+1 I like the idea
I tried out he bookmarks module a while back and I had one problem with it. I was not able to categorise or organise my bookmarks. Maybe that has changed now, I have not tested the latest cvs version.
It would be nice to bookmark some of the handbook pages, every time I create a cron on a drupal site I always search for cron and check to see if I have created it correctly.
Bookmarking or flagging great!
+1
It would be great to have bookmarking or flagging capability, maybe integrated with tracker.
This way the comments that are only made to put a thread in your tracker for surveillance will be redundant.
So not only would functionality and usability be improved - also the content on Drupal.org would be less diluted.
Best regards,
Lennart
Best regards,
Lennart
Browser?
How about using your browser's bookmark feature?
Browser not ideal solution
I think using the browser bookmark functionality is less than ideal.
For people who work at one and the same computer all the time, the solution is fine.
But many people may access Drupal.org from different machines, at work, at home, in the airport, in internet cafés.
Then all they will have to do is login to Drupal.org and all their bookmarks will be there regardless of their geographic location.
Of course there is a trade-off here, but I believe the benefit is bigger than the cost.
Best regards,
Lennart
Best regards,
Lennart
I used to use my browsers bookmarks..
till my computer crashed along with my personal settings.. :-(
Unfortunately I still use windows, and yes it still crashes on me..
The main reasons why I was supporting drupal bookmarks, instead of browser bookmarks is:
This automatically does one thing in the background [with a little extra work], it shows us which pages are popular (most bookmarked pages sorted by topic/forum)
I know, Drupal.org is accessed by many people a day, so simply switching on a module isnt a small deal.. and a few supporters isnt going to convince everyone either:)
So this is my argument:
Since "I would like to flag, bookmark or tag content/pages that interest me." scored 8% points on the Survey (the fourth highest percentage tied with 2 other options), it should atleast be considered.
Since you are planning on Rating Projects. Why not simply Rate Bookmarks pointing to Project pages? and Leave the Projects module as is. Maybe even enable rating of every page on Drupal, based on how many people have bookmarked it.
Since searching is already something that needs help, maybe searching can be improved by creating a second search option called, "Search Bookmarks" (the name implies what it would lead to:)
This is just a thought.. I just think it would be like solving the "Search", "Tracking" and "flagging" problems to some extent.
If only Bookmarks could be sorted into Categories, this could very well be Drupals own personal Dmoz like Web-Directory where people add the bookmarks - almost all pointing to drupal itself.
I think I've gone a bit overboard with the ideas.. I'll stop now.
Gautam Chandna
--
http://www.ahste.com
if your browsers bookmarks dont suffice: del.icio.us
in my del.icio.us, because i spent most of my time on dtupal.org, you will find nearly 70% of my bookmarks related to drupal.
del.icio.us can cater you FAR better then a bookmark module can ever do on drupal.org!
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
This isn't entirely
This isn't entirely true.
THe one thing that on-site bookmarks can do is a tracker-like page that shows me the activity of all bookmarked pages at a glance.
That is a feature I would really like.
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
I'll try it out..
I'll try it out at once, but my argument was not just to help my own personal problems with bookmarking..
I was trying to explain how simple bookmarks [or say tags if u like.. ] on drupal, could help organise data on drupal, for its users.
When everony bookmarks[tags] pages, there is no need for surveys to know what the problem is. There would simply be the need for a search among bookmarks.
This is just an example:
Say 100 people bookmark 2 page each, from a forum containing information about 3 different topics (support / handbook / forum).
Users get internal ranks (not shown publicly) based on number of posts given in support/handbook/forum topics. Handbook people get better ranking.
Searching can be done in the following ways:
Search "WORD" in Support, looking into the Bookmarks by people with higher ranking for the Support Topic.
I'm not too good with making modules, if someone is willing to make it.. I'm willing to help write a better model for such a search engine..
Gautam Chandna
--
http://www.ahste.com
I do
I do, but having the bookmarks in a block is just handier. Now that I'm forced to explain it, I guess I can't, really. LOL. I just know for the sites I do I love having the bookmark option to hit stuff I commonly use. I guess it's the same reason why it's easier to use the links in the sidebar than to have no navigation except a sitemap and tell people to go in and add bookmarks to the pages they want to use. Ok, maybe that's over the top, but it's the same general idea.
Michelle
I have 850+ browser
I have 850+ browser bookmarks relating to Druapl alone, relating to every forum posting/issue that I have been interested in or thought to be potentially useful for enhancing my knowledge of drupal. This is excluding the dozen pages in my tracker containing posts I have either created or to which I have replied. Both together make a nice haystack in which I try everyday to find the proverbial needle.
I have tried subscribing to projects/issues and my general experience is that it is overkill.
If the bookmarks were on drupal and tagging could be enabled for registered users, I could group these bookmarks by tagging them. Throw in the ability to show a page/block with tags that have updates(new posts) on my issues/forums postings and it makes things a lot easier to follow up.
I know there may not be an easy solution, but how I wish my bookmarks could be on drupal instead of my browser.
Food for thought
How do you envision tagging to work? Do you have your own personal tags, or can you see/use other people's tags? How do you browse or navigate these tags? How do you search within your tags?
Given your situation is rather extreme, it makes sense to turn your situation into a use case.
Frankly, I don't know how
Frankly, I don't know how tagging would work, but here are a few thoughts. Some of it may be wild, though.
Start with a base tag set
Instead of personal tags that users can create (and we would then have a real tag forest, wouldn't we;-)), I am in favour of a base set of tags defined by drupal.org admins that broadly covers various aspects of a user's drupal.org experience.
Defining the tag set
The process of defining this base set could be turned into an exercise that involves the drupal community, like the drupal.org survey and the documentation survey (where card sorting was used) so that no one complains the base set has been thrust upon them. May be an initial survey where users submit tags, followed by a poll for the final list of tags?
Making the tags available
These tags would then be available for the user to configure on the 'my account' page (subscribe or unsubscribe?). Once a user subscribes to certain tags, these should show up in the user block that appears on logging in (check boxes or drop down list?). When the user comes across a forum posting/issue/bookpage they want to track, they pick one of the subscribed tags to associate that posting with that tag. Drupal.org would remember the association.
Navigating the tags
The next step would be to display the nodes (forum topics/issues/book pages) thus tagged. One option would be to add a 'my tags' tab for every user. This would give a page listing all the nodes that have been tagged by the user.
Displaying subscribed tags with node listings as blocks
To improve the experience even further, I think this page should use the regions feature of 4.7 (if I understand this correctly) to present the subscribed tags as blocks in the main content area instead of one huge listing like the current 'my recent posts' page. Each block would have the title of the tag to which the user subscribed and beneath it, list the nodes (forum topics/issues/book pages) associated with those tags that have been updated recently. The number of this listing could even be a configurable option in the 'my account' section, but at least 10 nodes would be a reasonable default, I think.
Alternative display options
If the base tag set is a very high number and a user subscribes to many or all of them, instead of showing tag blocks with the node listings, we could simply list the tags themselves on the 'my tags' page, with a number in parentheses showing the number of subscribed nodes and another showing the number updated, like this: audio (10 subscribed) (3 updated). By clicking on the '3 updated', the user would be taken to a page with the 3 updated nodes. Personally, I think this would be a less useful experience than option 1 above of presenting in blocks.
Caveats
At this moment, I don't know if implementing something like 'my tags' would make the 'my recent posts' section redundant/duplicative. And, I really don't know about searching the tags. Also, I have left out 'project', the other piece of content that a user can create on drupal.org today. I haven't thought about how this would interact/integrate with a tag system.
I am sure there are some grey areas in my suggestions and I don't have any idea how doable all this is or the overhead it will cause for the drupal.org infrastructure, but hopefully this feedback was useful.
All I wanted...
Wow, that's pretty complex. LOL! All I was hoping for when I added my "+100" was to be able to have a block where I could add things like "my posts" and "my issues" so I could get to them with one click. The existing bookmarks module would work great for that.
Michelle
Complex indeed! That was
Complex indeed! That was just a bit overboard, perhaps:-)
If the bookmarks were on
Sounds like del.icio.us provides this functionality?
-- Merlin
[Point the finger: Assign Blame!]
[Read my writing: ehalseymiles.com]
-- Merlin
[Read my writing: ehalseymiles.com]
[Read my Coding blog: Angry Donuts]
del.icio.us?
an option which would provide always online bookmarks, with tagging, would be integration with http://del.icio.us/
More feeds on Drupal.org
I would love it if there was a feed to let me know when a new module was added to: http://drupal.org/project/Modules
For that matter each module could use its own feed for when new versions are released. It would be great for admins who want to make sure they want to stay up to date (I know they can use CVS).
Just my 2 cents from my experience on drupal.org
I use this...
http://drupal.org/taxonomy/term/14
Modules by date. Helps to see what's new.
Michelle
And here's an RSS feed of that...
http://drupal.org/taxonomy/term/14/0/feed
Feed page
Is their a page or block that lists all available feeds on drupal.org
almost infinite
That pae would not be useable, there are too many.
A handbook page may be useable though on how to create feed URLs from normal ones.
--
Read my developer blog on Drupal4hu.
--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.
What about a page promoting
What about a page promoting the important ones like http://drupal.org/taxonomy/term/14/0/feed
important for you != important for me
I track about 20 *important* feeds on Drupal.org. And I doubt you will need even one of them. No, a bookpage describing the way to get feeds would be great. PLease start it, if you think you need it :)
---
if you dont like the choices being made for you, you should start making your own.
---
[Bèr Kessels | Drupal services www.webschuur.com]
hacking drupal.org url
There's a list of taxonomies here, with XML links at the bottom of each page...
http://drupal.org/node/16489
Thanks
That is exactly what I was looking for. Just a list of all the important ones. Now this is the type of page I would bookmark.
Thanks.
Of course.
Thanks for reminding me to think of the bigger picture. I've never used the project module before, and hadn't thought that it would be associated with a taxonomy. Very cool. This is exactly what I was looking for.
slightly OT, new posts hard to find
This is slightly off topic. I think it's almost impossible to find new posts within a really popular forum discussion. "Sliced Bread... PHP Snippets" comes to mind. I'll track my posts to find someone has added something there and usually give up on finding it because it's been a really popular topic. Basically, NEW needs to be bigger, bryghter, or blinking.
Or have an addition...
Yup it takes ages to find new stuff - you could turn 'new' into '*new*' as I mentioned here so you can do a local search....
><>tomskii
><>www.mutinyarts.co.uk
One fairly easy way to do this...
Would be to set a class name for "new" post as well as "my" posts, then the background colours of those comments could be changed with CSS (maybe bright yellow for "new", bright blue for "my").
I will see if I can roll a patch for comment.module later today that would do this.