Glen- Thanks for your feedback. I've started a Google Document with this information, it's just a skeleton right now. It can be viewed publicly at: http://docs.google.com/Doc?id=dgv8xf4f_54fchbjkc3
If anyone would like access, please contact me directly. I currently have plans in my head for how to approach the development of the new site, and how to manage the migration process. I'm not sure how to communicate this, other then to just go ahead and do it, after we've finalized and agreed to the planning document. My approach reflects my own style and my goal of getting a quality product as fast as possible. I'm open to feedback on this. One area where I know I will need a bit of help is in the graphical design arena. Should I connect with Scott Jehl, the guy who designed the main site? I fully plan on using the current Drupal theme, but the individual page designs, (CSS and Graphics) are not my best strength. I can certainly tackle them, and leave room for improvement, but I think that the jQuery community deserves and expects a certain level of quality here. Thoughts? Mike Hostetler http://amountaintop.com On Sun, Oct 19, 2008 at 13:47, Glen Lipka <[EMAIL PROTECTED]> wrote: > > Just a bit of "best practice" for designing a better experience: > > 1. Create personas. (1-2 hour) These are basically a list of the > people who matter and their different "types". > Example: New jQuery fan looking for a simple autocomplete. Name: > Chuck. What chucks wants: confidence the plugin is a good one. > options, comments, etc > Example 2: Advanced jQuery plugin author. Name: Sarah. What sarah > wants: SVN Access, simple updating, etc > There should be around 5 personas or so. (Less than 10) Give them > pictures. I swear to god, it makes the whole process easier. > > 2. Write down use cases (a.k.a. user stories). (2-6 hours) These are > REALLY helpful to manage the requirements. If your implementation can > achieve these use cases, then you know you didnt forget something > like. "Sarah needs to change her password for SVN". > > 3. Design the user experience in something simple/fast/cheap. I > suggest powerpoint, but it could be anything. Just so long as it is > the cheapest fastest possible way to show how the thing should be > built. > > 4. Eat your own young. Please don't get hung up on drupal or existing > ideas/systems. Redoing something ALWAYS is better than trying to > shoehorn an update. Starting from scratch is fun. Go for it! You > might end up choosing drupal again, but don't let a bad decision > before affect your decisions today. > > 5. Iterate. It's important to leave room for growth. Wouldn't it be > nice for people to vote for a plugin that doesn't exist? or to pay a > plugin author money to extend it? ideas are powerful. > > Anyway, I wish I had more time to devote to jQuery. :( So much > powerpoint these days. > > I'd be happy to help anyway I can. :) > Keep "pluggin" away! > > Glen > > > > On Oct 19, 12:27 pm, "Jörn Zaefferer" <[EMAIL PROTECTED]> > wrote: > > Thanks Rey for sharing ypur AMO experience! > > > > Afaik doing away with hosting wasn't an option anyway, only project > > management doesn't fit the picture. > > > > You're right that reviewing is a lot of work and requires resources we > > probably don't have. A less involved alternative would be to write > > down criteria that good plugins should adhere, and just check if those > > are met, and if so, highlight the plugin as such. This would cover > > aspects that a potential user would usually check before deciding to > > use a plugin, like presence and completeness of documentation. > > > > Jörn > > > > On Sat, Oct 18, 2008 at 5:31 AM, Rey Bango <[EMAIL PROTECTED]> wrote: > > > > > Sorry for jumping so late into this discussion. Thanks for the kudos on > > > Mozilla AMO Joern. > > > > > The AMO add-on site is pretty involved. While it looks very simple on > > > the front-end, there's quite a bit going on on the back-end that helps > > > us add, disable, review, approve, diff and version add-ons. > > > > > While I like some of the ideas being thrown around, I'm not convinced > > > that doing away with hosting is the answer. The fact that we have a > > > central place for developers to come to to find plugins is a very > > > important advantage to the project. Although there are many plugins for > > > similar functionality, the fact that we have so many also needs to be > > > viewed as a "positive" as it offers choice to our user base. Having > lots > > > of choices does make things confusing but I'd rather have a little > > > confusion than nothing to offer at all. In addition, there have a > number > > > of cases of add-ons that have been seemingly abandoned in the repo get > > > resurrected by a user who needed the functionality and took it over. > > > > > If anything, I would like to see a combination of both a hosting > > > scenario and directory listing. This would allow those developers that > > > wanted to upload their plugin a place to house it while those that > don't > > > can simply point back to their site. > > > > > I do think, as has been mentioned, that we need to get a better system > > > in place to properly categorize the plugins. On AMO, for example, we > > > have multiple categories but we also offer a recommended list of top > > > add-ons (about 40 of them) and in addition, for each category, we offer > > > a list of category recommended add-ons. This has been hugely successful > > > and in fact, motivates many add-on developers to really improve the > > > quality of their work. I can see the same thing being very beneficial > to > > > the jQuery repo. So going with what Joern said, I think we need to get > > > back to listing our official plugins the way that we used to and also > > > create a recommended list of add-ons that we know are top-notch. > > > > > In terms of reviewing add-ons, understand that it would be a VERY big > > > task. On AMO, we struggle with that daily because of the number of > > > submissions as well as the time involved in reviewing the add-ons. At > > > this point, I'm not sure if we're prepared to take on that task unless > > > we were able to get a good group of volunteers to check the plugins. > > > It's definitely a good idea and again, would help the community by > > > giving them feedback on improving their work. > > > > > As for SVN, project management, etc, these are features that are way > > > outside of the scope of a plugin repo. This is something that we should > > > *NOT* do. We don't do this on AMO because of the complexity of this. On > > > AMO, we host the files necessary to install and add-on and that's it. > > > The developers use other services for managing their project (eg: > > > MozDev.org or Google Code). > > > > > I would say that in order to do this the right way, we would probably > > > need to build our own custom system. At the moment, Drupal doesn't seem > > > to provide the best way to find plugins and perhaps it's because it's > > > not meant to do so. > > > > > Rey... > > > > > Jörn Zaefferer wrote: > > >> That sounds very good to me! Releases usually consist of a download, a > > >> version number and a changelog. Thats all the repository should touch > > >> in terms of project hosting - thats also what for example > > >> addons.mozilla.com provides. Defining a convention to provide these > > >> via Google Code or a Wordpress blog with minimal effort would free > > >> other resources to focus on discussion and promotion of plugins. > > > > >> Jörn > > > > >> On Tue, Oct 14, 2008 at 6:17 PM, Diego <[EMAIL PROTECTED]> wrote: > > >>> That would make sense because drupal is very poor and every plugin > > >>> I've ever come across has its own homepage hosted elsewhere. Maybe > > >>> plugins.jquery.com should focus on being a community for users - not > > >>> developers of jQuery - allowing users to... > > >>> - 'watch' their favourite plugins > > >>> - discuss/get help from fellow users > > >>> - share / rate / comment > > >>> - post related links to demos / tutorials > > >>> - stay up-to-date with the latest releases > > > > >>> And the latest releases could be simply based on an XML feed form the > > >>> author's own website - it's probably safe to assume every plugin > > >>> developer has one... > > > > >>> You can't please everyone - so focus on pleasing the users and let > the > > >>> developers manage their projects however they're most comfortable > > >>> with... > > > > >>> How about that? > > > > >>> Cheers, > > >>> Diego A. > > > > >>> On Oct 14, 4:00 pm, "Nathan Bubna" <[EMAIL PROTECTED]> wrote: > > >>>> +1 get out of the plugin project hosting business. make the plugin > > >>>> site a way to list/find/promote plugins, not a place to manage them. > > > > >>>> On Tue, Oct 14, 2008 at 2:34 AM, Diego A. <[EMAIL PROTECTED]> > wrote: > > >>>>> Hi guys, > > >>>>> I agree with all the points raised by Yehuda and Jorn, but > unfortunately > > >>>>> Mike, the biggest problem of all is Drupal. > > >>>>> In a nutshell :- > > >>>>> - The navigation is shocking > > >>>>> - Issue management is long winded and painfully time-consuming > > >>>>> - So is uploading new files / creating new releases > > >>>>> I feel Yehuda and Jorn's points are great, but they focus primarily > around > > >>>>> giving jQuery user's better access to plugin - which is undeniably > a > > >>>>> must-have great idea. However, The system must also cater for those > who do > > >>>>> (and will) voluntarily maintain their projects within the > community. > > >>>>> With that in mind, I recently moved all my plugins to Google code > for the > > >>>>> following reasons :- > > >>>>> - Sub-version access > > >>>>> - Easy navigation > > >>>>> - Easy-to-use issue management system (with configurable email > alerts) > > >>>>> - WIKI (for project documentation) > > >>>>> - Ability for project collaboration > > >>>>> Hope that helps in some way... > > >>>>> Cheers, > > >>>>> Diego A. > > >>>>> 2008/10/13 Mike Hostetler <[EMAIL PROTECTED]> > > >>>>>> Hi Everyone- > > >>>>>> I'd like to start a discussion on how we can improve the plugins > > >>>>>> repository to better fulfill the needs of the community. When we > > >>>>>> first created the plugins site, there were a lot less plugins. As > > >>>>>> jQuery's popularity continues to rise, the need for additional > > >>>>>> features for plugin authors is growing. > > >>>>>> As the person most familiar with the plugins site, I get a decent > > >>>>>> amount of requests for tweaks here and there. Unfortunately, > because > > >>>>>> of the choice of using Drupal with Drupal's Project module, the > amount > > >>>>>> of features that can be easily turned on is small. I've been very > > >>>>>> cautious at modifying the source code of the Project module for > many > > >>>>>> reasons. I'm in touch with the leaders of the Project Module, > having > > >>>>>> met up with them at the last Drupalcon. Currently, there is > ongoing > > >>>>>> work on the Project module for Drupal.org, and the Project module > > >>>>>> remains the last major issue in upgrading Drupal.org to Drupal 6. > So, > > >>>>>> this problem is bigger then jQuery. > > >>>>>> What I'd like to solicit is feedback on the following: > > >>>>>> - What works with the current plugins site, what are it's > strengths? > > >>>>>> - What doesn't work, where does it fall down? > > >>>>>> - What are the top 5 major features missing from the current site? > > >>>>>> - Are there any other open source project management solutions > that > > >>>>>> are worthy of consideration to replace Drupal and the Project > module? > > >>>>>> (PS. Because of the work involved in this, I would consider this > only > > >>>>>> as a last resort) > > >>>>>> - Any other feedback is appreciated > > >>>>>> Thanks, > > >>>>>> Mike Hostetler > > >>>>> -- > > >>>>> Cheers, > > >>>>> Diego A. > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en -~----------~----~----~----~------~----~------~--~---
