From: Francesco M. <f18...@ya...> - 2005-07-08 15:02:15
|
Hi, I've just completed the new viewmode "as single table"; I also did some important modification to the log in system which however still needs some last touchs... (however everything is working). I'm now going to complete the "template" module so that anyone can update its component website.... however I have to say that we have 23 registered components in the DB and 45 components in the CVS.... they should be registered in the DB but I suspect that most of them are unmantained... am I right ? In this case, should we remove them ? Francesco Francesco Montorsi wrote: > Hi, > > Otto Wyss wrote: > >> Registration: 1. I'm not sure but I thought there's a way to use the >> sf login (look in >> the SF docs). > > no; there's no way to do that... also because SF uses secure HTTP > connections (through SSL or HTTPS) while project websites cannot use > these things... > > >> Add Components: 2. The creation date isn't very useful but the last >> file release date or >> version is. External dependencies aren't used very often, so they should >> only be mentioned inside the component. Dito category. > > I've replaced the "creation date" field in the component list with > "latest version" field... even if the cdate is still a useful info and > thus I think it's best to keep it, at least in the DB. > > Instead I think that external dependencies are very important and must > be listed: think to all those components which are a "bridge" between > two libraries (like wxXml2 which connects libxml2 & wx, or wxScript > which connects lua, python, cint, underc & wx); they need various > external dependencies. > > And the presence/absence of external dependencies is an important factor > when choosing to use or not to use a component... > > Last, I think category will be useful in the search page (which I'm > working on). Also it would be more important if we could imagine more > component categories and update the DB accordingly... > > >> 3. The description should be limited to say 300 chars. > > yes, that could be a good thing; however I'm unsure on how to do it: > should I just truncate the description string ? > Maybe it's best to add "... [more in the component website]" string... > > >> 4. I would remove the rest of the fields since the contain most of the >> time the same infos and can be mentioned within the component. Only the >> first and the last wxWidgets version makes sense. The last version gives >> also a hint if a component is still supported. > > wxCode is a site specialized in wx-component hosting: I think we should > try to give to the users as much info as possible on the components and > provide these info in a standard form: i.e. not force them to search for > such info into the component websites & render them on the component > list page all with the same format. > Sure, those info can be mentioned also in the component websites but why > shouldn't we keep them in the DB, too ? > Also, I think I'll remove those redundant info from my component > webpages so that it will be easier for me to update those info (using > the edit form). > > Think to SF (which is conceptually very similar to wxCode: they both > host thirdparty projects): if the project info (status, category, > author....) would be removed from the project pages (those which begin > with http://sourceforge.net/projects/xxxx) then it would be much more > difficult for the user who search Open Source software to understand if > he has found something good for him: instead of using the project pages > as a preliminary filter he would be forced to search in the single > websites... it would be a nightmare (for me at least) ! > > >> Component list: >> 5. Without colour (Setting: use always my colour) the list is not easy >> readable. At least a small line should be drawn between the components. > > the component list is quite coloured; each component table has a grey > background & the field values are printed in green... the links have a > rollover effect and each component entry is separed from the previous > one by a blue heading... why do you say it's without colour ? > Is your browser CSS-enabled ? > > >> 6. Description texts should not be bold nor any infos except the >> component names. > > fixed; > > >> >> 7. The field names shouldn't be repeated in each component but belong >> into a header. > > I tried such approach but it made the list horrible because: > 1) to show a decent number of field we would be forced to make a > very-wide complist page and thus the user should be forced to > continuosly scroll horizontally the page > 2) the space would not be used correctly since some rows take much more > space (in vertical) than others... > > still I think that a table containing the *very basic* info about > components (name, latest version & description) could be useful to have; > I'll add it to the view mode next to full & compact. > > >> 8. I'd prefer the component's infos were links instead of links at the >> bottom of each component (analog old list). > > the problem is: in which component info should the wiki link be placed ? > also in which component infos should all other links be placed ? > > >> 9. I hate paged lists so I always set the count to 99999 but it's still >> a little anoying. > > I could make cookies also for the complist page so that it remembers > your favourite view options.... > > Francesco > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual > core and dual graphics technology at this free one hour event hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > wxCode-users mailing list > wxC...@li... > https://lists.sourceforge.net/lists/listinfo/wxcode-users > |