[dokuwiki] Re: [GSoC 2011] Plugin and template manager enhancement
- From: Piyush Mishra <me@xxxxxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Mon, 28 Mar 2011 18:48:13 +0530
On Sat, Mar 26, 2011 at 12:12 AM, Håkan Sandell <sandell.hakan@xxxxxxxxx> wrote:
> Nice start and good looking pictures. The only thing I guess will bug
> me might be how fast I can enable/disable one of my 40+ plugins in my
> installation. Well I don't think this is a common case,
> but we could check that with our popularity data. Andi?
One simple option could be using something like data tables so that
the filtering etc can be done on that in presence of JS and probably
using regular php if no JS is present? also from what I made out of
the whole thread, showing only the plugin names with toggle click
would be good so I can keep 50-100 plugins in the list.
> Do you have any thoughts on how to handle the "compatibility"
> information? Our main problem is that
> plugin might work in a DokuWiki version even if they doesn't
> explicitly say so. Any central testing is
> out of the question with 700+ plugins.
>
may be a "la - WordPress" works for me button on the plugin list?? or
rather a report broken link so that whatever isnt said to be broken
can be given lower priority in search results from that particular
version? May be we can give weightage to reports from known
developers?
On Sat, Mar 26, 2011 at 5:58 PM, Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote:
>> Pagination to keep the page smaller and easier to manage.
>
> I'd try to keep the interface simple so I'd not use pagination.
> Instead I'd just show minimal information in the list and expand the
> item to reveal more information when clicked. This way it should be
> fine show 50 or even 100 plugins on a page.
hmm, what about keeping the pagination limit to 50/75 or 100?
I feel that not many people would be sending plugin requests or
reporting bugs on plugins even when they have to come to
http://www.dokuwiki.org/plugins to look for new plugins not because
its a new task to do but because they wouldnt reach the end of page in
most cases unless they click to filter by some really unpopular tag.
The original idea was to add pagination on that page and then I
figured out why not on individual installations, probably with a very
high default limit?
> Info should also contain links to the bugtracker, source repo and
> donation link for the plugins.
Yes, all the info on http://www.dokuwiki.org/plugin:repository and
possibly more (eg:- Works on which version as I mentioned above)
>> Plugins are downloaded as disabled by default.
>
> Hmm that changes behaviour from the current implementation. I'm not
> sure that's a good idea.
Looking from that point, yes it may upset a lot of people. probably
both "Download" + "Download and Activate/Deactivate" buttons
(according to what we decide as the default behaviour)
Downloading as deactivated button is for people who would want to test
/ go through the plugin code before activating it. (Probably an
activate for 2 minutes option to let the users test the plugins
behaviour in their istallation? Does away with the preview etc trouble
in case of plugins)
>> A rating /feed back system on the side for users with online Wikis to
>> help in giving out better search results.
>
> Not sure about this. We'd need additional infrastructure in the
> backend. It might be a good addition later on, for now I suggest using
> popularity data instead.
In future we'll have to find a better fix for it though. As I
mentioned in this mail earlier, a report broken link perhaps?
What do you think?
> One more thing: I'd like to still have the option to install a plugin
> via URL (as we have now) and additionally it would be nice to have a
> way to upload a plugin package to have it installed (for wiki's behind
> restrictive firewalls).
I did mention half of that in my mail.
I had planned these in the Browse section (as you said, Search and
Browse can be merged into Browse only)
For the upload plugins part, totally agree!
Some more thoughts,
"view code" button on description / info to make it easier to see the
codes from the interface, (may be color coded, only if time permits)
as mentioned on IRC and some mailing list threads for security.
from the testing side-
As mentioned in the testing system idea, we have to make a huge data
set to test almost all possible setting under which DokuWiki can run
and test on that. this will probably be useful in determining if a
plugin is working or broken (plugin-DokuWiki version compatibility)??
On templates-
A live preview in a iframe / new tab before activating is a good idea.
this can also help people making the template debug faster.
I am sorry I couldnot reply faster and cannot iterate on the design to
show a new one right now as I am in a different city and get internet
access only from cafes
--
Regards
Piyush Mishra
http://www.piyushmishra.com/
Life's Short, Live it to the maximum
--
DokuWiki mailing list - more info at
http://www.dokuwiki.org/mailinglist
Other related posts:
