Menu
▾
▴
pyblosxom-devel
|
From: will kahn-g. <wi...@bl...> - 2011-03-19 02:42:26
|
I reworked a ton of content on the web-site, removed a bunch of stuff, added some new things, and reorganized everything. http://pyblosxom.bluesock.org/ There are some outstanding things that need to be done: 1. we need to finish up changes to the documentation, then compile that and push it to the site -- Sean has done a ton of stuff and I haven't caught up with looking through those changes, yet. 2. we need to finish up updating the plugin registry 3. we need to finish up updating the flavour registry After that, I think the web-site is good enough to do a 1.5 release. After 1.5 we should talk about other things we can do to improve the site. Improving the look-and-feel is probably a good thing to work on. I'd love to hear people's thoughts and whether there are other critical things we should improve now. Particularly on the following things: 1. the features list on the front page -- are there other things we should mention? things we shouldn't mention? 2. the quick start section on the front page -- it's slightly more complicated than these steps, so I wasn't sure whether to include them or not, but I really like the idea of having a quick start 3. the "how to send us a patch" section on the development page -- do those instructions look adequate? how would you improve them? 4. the navigation items in the sidebar -- is it saner than it was before? are there better names for some of the sections that we should use? I've pushed all the changes to the pyblosxom-web repository. Many thanks to Sean and Dieter for their thoughts and feedback so far. /will |
|
From: Dieter P. <di...@pl...> - 2011-03-19 10:19:11
|
On Fri, 18 Mar 2011 22:42:15 -0400 will kahn-greene <wi...@bl...> wrote: > I reworked a ton of content on the web-site, removed a bunch of stuff, > added some new things, and reorganized everything. > > http://pyblosxom.bluesock.org/ > > There are some outstanding things that need to be done: > > 1. we need to finish up changes to the documentation, then compile that > and push it to the site -- Sean has done a ton of stuff and I haven't > caught up with looking through those changes, yet. > > 2. we need to finish up updating the plugin registry > > 3. we need to finish up updating the flavour registry > > > After that, I think the web-site is good enough to do a 1.5 release. > After 1.5 we should talk about other things we can do to improve the > site. Improving the look-and-feel is probably a good thing to work on. > > > I'd love to hear people's thoughts and whether there are other critical > things we should improve now. the links "report bug" / "request feature" point to the same. why not just one link "bugtracker" or maybe "bugs / tickets" but I think 'bugtracker' is clear to everyone that it also includes feature requests and/or misc tickets. > > 1. the features list on the front page -- are there other things we > should mention? things we shouldn't mention? * the last line basically repeats the 2nd point. imho remove it entirely. * "works with blog standards" -> maybe mention this is done through templates so that people don't think the core has bloat for that built-in. * otherwise I think this bullet list is very accurate and clear. > 2. the quick start section on the front page -- it's slightly more > complicated than these steps, so I wasn't sure whether to include them > or not, but I really like the idea of having a quick start instead of [ edit config.py ] you could put $ $EDITOR config.py > 3. the "how to send us a patch" section on the development page -- do > those instructions look adequate? how would you improve them? * has a typo commet -> commit * an alternative for patches is pushing commits to gitorious (or any other public git repository) and issuing a pull request (in the latter case, a pull request is basically a mail saying "please pull from that repo/branch") looks ok otherwise. > 4. the navigation items in the sidebar -- is it saner than it was > before? are there better names for some of the sections that we should use? * you can put me on the pyblosxom users page. my blog is @ http://dieter.plaetinck.be/ * the section "documentation" with 2 subitems, one of them being "documentation" is a bit weird. maybe append the two links to the upmost list (i.e. add them below the link to bugtracker) * users and registries could get their own title. like "Community". then, under community you could put also a link "Get in touch" which contains the mailing list and irc info. that might be a better place then the home page for it. imho the home page should be short and focused. (readable without scrolling) so if you can get the irc/mailing list info away from there.. maybe also remove the "Bugs/Features" section. after all there are links to that from the main menu. Dieter |
|
From: will kahn-g. <wi...@bl...> - 2011-03-19 20:56:19
|
On 03/19/2011 06:19 AM, Dieter Plaetinck wrote: > On Fri, 18 Mar 2011 22:42:15 -0400 > will kahn-greene <wi...@bl...> wrote: > > the links "report bug" / "request feature" point to the same. why not just one link "bugtracker" > or maybe "bugs / tickets" but I think 'bugtracker' is clear to everyone that it also includes feature requests and/or misc tickets. That makes a lot of sense. Fixed! >> 1. the features list on the front page -- are there other things we >> should mention? things we shouldn't mention? > > * the last line basically repeats the 2nd point. imho remove it entirely. You're right! Fixed! > * "works with blog standards" -> maybe mention this is done through templates so that people don't think the core has bloat for that built-in. I'm going to be a bit hard here, but bear with me. I think the "bloat" word is overused and really means "the software has code for things I don't use" which is true of all software for all people. If people think that of a file-based blogging system and it's a turn off, then they're not the sort of people I want to deal with anyhow. I'm pretty ok with them not using PyBlosxom. So there's that. I think it's important that PyBlosxom works with blog standards, so I think that should be in the list. However, it really should include feeds as well as some of the other standard blog things like pingbacks, trackbacks and things like that. PyBlosxom has plugins for those, but I have no idea if they work anymore and even if they did, they should probably get re-written to use 1.5 awesome-happy-goodness. So while this is in the list, I think we're actually kind of failing on this front. I think I want to leave it for now, but recognize that this line is debatable. I'd also be interested in whether there are other blog standards that we should be supporting. What is PyBlosxom missing to interoperate better with other blog systems? >> 2. the quick start section on the front page -- it's slightly more >> complicated than these steps, so I wasn't sure whether to include them >> or not, but I really like the idea of having a quick start > > instead of [ edit config.py ] > you could put $ $EDITOR config.py I thought about this for a while and I think I prefer the "[ edit config.py ]" since it's a general instruction even though it doesn't fit in with the other things which are shell commands. I'm not sure it's true that all people have an $EDITOR environment variable. So I think changing it to "$EDITOR config.py" possibly makes it applicable to fewer people. >> 3. the "how to send us a patch" section on the development page -- do >> those instructions look adequate? how would you improve them? > > * has a typo commet -> commit Oops! Fixed! > * an alternative for patches is pushing commits to gitorious (or any other public git repository) and issuing a pull request (in the latter case, a pull request is basically a mail saying "please pull from that repo/branch") > looks ok otherwise. I really dislike the gitorious merge request thing. I know you didn't mention that, but I'll just put it out there. It's entirely possible I'd like it more if I could figure out how the damn thing works without picking up all patches everywhere. Pull requests are interesting, too, but they require that someone's clone is in a public place that I can pull from. I think just talking about git format-patch is a lower common denominator, so I think I just want to go with that. >> 4. the navigation items in the sidebar -- is it saner than it was >> before? are there better names for some of the sections that we should use? > > * you can put me on the pyblosxom users page. my blog is @ > http://dieter.plaetinck.be/ Added! > * the section "documentation" with 2 subitems, one of them being "documentation" is a bit weird. > maybe append the two links to the upmost list (i.e. add them below the link to bugtracker) Done! > * users and registries could get their own title. like "Community". then, under > community you could put also a link "Get in touch" which contains the mailing > list and irc info. that might be a better place then the home page for it. > imho the home page should be short and focused. (readable without scrolling) so if you can get the > irc/mailing list info away from there.. maybe also remove the "Bugs/Features" section. after all there are links to that from the main menu. I put them in a Community section and added links for the two mailing lists and IRC. I have them link to the respective sections on the front page. One of the things I really want to do is bring together all the critical bits of information someone needs to know. So from the front page, someone ought to be able to: 1. evaluate pyblosxom in regards to whether they should use it 2. find information about mailing lists and irc 3. download the software 4. get the source code 5. report bugs/features 6. contribute patches Those are the critical actions that encompass the human side of the project. I want to experiment with putting all these things on the front page rather than separate them out into a few different places. I'm also not sure that the "readable without scrolling" rule is compelling. What's the motivation for that rule? I would definitely be interested in project pages you find compelling as well as what requirements you (or anyone else reading this email) think a project front page should have. /will |
|
From: Dieter P. <di...@pl...> - 2011-03-19 21:21:41
|
On Sat, 19 Mar 2011 16:56:08 -0400 will kahn-greene <wi...@bl...> wrote: > I'm also not sure that the "readable without scrolling" rule is > compelling. What's the motivation for that rule? my reasoning was: if you add links to that information in the menu, you should remove it from the home page, otherwise there would be some redundancy - which in my case always causes confusion, which is a bad thing. Example: when the frontpage has a section "IRC" but the menu also has a link "irc" I will wonder if they point to different information, and if so, which one is the most useful/up-to-date; i will have a click glance at the irc info, then click the link and see what happens. all this mental overhead can be avoided by removing all redundancy. (and it makes the page a tiny bit simpler as well) However, I think your goal of having all critical on the homepage is nice too. so just ignore me, first of all, I don't know what I'm talking about, and even if i was this can debated endlessly with very little possible benefit, your way is fine. > I would definitely be interested in project pages you find compelling as > well as what requirements you (or anyone else reading this email) think > a project front page should have. I like http://uzbl.org/ , nearly all the content there is generated from the documentation within the project, and I find it easy to navigate. but that doesn't mean you should do it like that. I don't know much about UX. Dieter |
|
From: seanh <sn...@gm...> - 2011-03-26 21:53:12
|
On Fri, Mar 18, 2011 at 10:42:15PM -0400, will kahn-greene wrote: > 1. we need to finish up changes to the documentation, then compile that > and push it to the site -- Sean has done a ton of stuff and I haven't > caught up with looking through those changes, yet. There is still much more that could be done to improve the documentation, but I think I'll give it a rest for now and wait for you to catch up with my commits. I'm not sure how far along you are with accepting/rejecting/modifying them. > 2. we need to finish up updating the plugin registry > > 3. we need to finish up updating the flavour registry Is the plan to move both of these to the coming pyblosxom wiki? If so I think it might be good to setup the wiki first then we can update the registries as we move them over to the wiki. I noticed the gitorious has built-in wikis, but I haven't tried it out to see if it might be suitable. The main thing that I think the new website needs is for the news posts to be on the front page. Currently there is nothing on the front page for people who are re-visiting the site rather than visiting it for the first time, and there's nothing to immediately tell people what's new. Having the full contents of the posts on the front page would be too long, but maybe it could have just the titles of the three most recent posts, or titles and previews/summaries, linked to the full posts. This might fit into the sidebar. There's a good example of this on the banshee site: http://banshee.fm/ |
Thanks for helping keep SourceForge clean.
X