Talk:Wiki wish list - Revision history

Cr144: /* See the plus at the top of the page? */ new section

2011-02-25T10:46:51Z

See the plus at the top of the page?: new section

← Older revision		Revision as of 10:46, 25 February 2011
Line 72:		Line 72:

	12:38, 28 November 2010 (PST)		12:38, 28 November 2010 (PST)

			== See the plus at the top of the page? ==

			That is the best way to start a new topic discussion

			:Then each new reply,

			::should be indented

			:::and signed <nowiki>~~~~</nowiki>

			::::so that people can read the conversation years later and know the dates and people involved.--C 02:46, 25 February 2011 (PST)

Marie.Byleen: mission comment

2010-11-28T20:38:08Z

mission comment

← Older revision		Revision as of 20:38, 28 November 2010
Line 66:		Line 66:
	** I don't get everything right the first time		** I don't get everything right the first time
	** Refactoring a category is fairly easy, at least easier than setting up the category in the first place		** Refactoring a category is fairly easy, at least easier than setting up the category in the first place
			----
			I think it may be the case that the categorization of info not related to the GVCS is especially slippery because some of it can't be categorized at the level of page. There are some pages from different time periods hanging around that contain information that I would want to separate into different categories. The pages could be multiply categorized to account for the content of all of the subtopics, but I think that would lower accessibility.

			I am preparing to gather all the information regarding volunteering together in order to compare, eliminate redundancy, replace outdated information, and connect all of it together by categorization and metatopic -> topic links so that people who do want to volunteer know what all of the different ways to do so are, and can find the information they need. Accessibility of this particular body of information is very low right now, IMHO. Should take some time.

			12:38, 28 November 2010 (PST)

Dan at 02:03, 28 July 2009

2009-07-28T02:03:20Z

← Older revision		Revision as of 02:03, 28 July 2009
Line 57:		Line 57:
	* Going top down in that way would leave us in a world of pain I think. If we produce draft headers to allow anyone playing with refactoring to work through things, and just include the sections that are done from the bottom up into the existing headers when they are ready then there shouldn't be any issues with existing stuff becoming inaccessible.		* Going top down in that way would leave us in a world of pain I think. If we produce draft headers to allow anyone playing with refactoring to work through things, and just include the sections that are done from the bottom up into the existing headers when they are ready then there shouldn't be any issues with existing stuff becoming inaccessible.
	* I'll go through one of the smaller packages and do some refactoring according to the new scheme later in the week. There are sure to be other issues picked up as the system is actually implemented.		* I'll go through one of the smaller packages and do some refactoring according to the new scheme later in the week. There are sure to be other issues picked up as the system is actually implemented.
			----
			* I've been playing with this scheme in another wiki, and I've reached a few conclusions:
			** '''=>''' looks better than '''->'''
			** '''(Subcategory 1, Subcategory 2)''' looks better than '''(Subcategory 1 \| Subcategory 2)'''
			*** The commas are closer to English, which the vertical bar is used for wiki markup. Commas are less confusing all around.
			* Bottom-up refactoring works pretty well
			** There is a certain amount of overhead per category
			** I don't get everything right the first time
			** Refactoring a category is fairly easy, at least easier than setting up the category in the first place

Geoff at 02:11, 27 July 2009

2009-07-27T02:11:51Z

← Older revision		Revision as of 02:11, 27 July 2009
Line 54:		Line 54:
	#* I've added a [[Using header templates\|page describing the header templates]].		#* I've added a [[Using header templates\|page describing the header templates]].
	# If you'd like to put together a top-down skeleton category structure, go ahead. I tend to think this needs to be approached from the bottom up.		# If you'd like to put together a top-down skeleton category structure, go ahead. I tend to think this needs to be approached from the bottom up.
			----
			* Going top down in that way would leave us in a world of pain I think. If we produce draft headers to allow anyone playing with refactoring to work through things, and just include the sections that are done from the bottom up into the existing headers when they are ready then there shouldn't be any issues with existing stuff becoming inaccessible.
			* I'll go through one of the smaller packages and do some refactoring according to the new scheme later in the week. There are sure to be other issues picked up as the system is actually implemented.

Dan at 02:36, 22 July 2009

2009-07-22T02:36:17Z

← Older revision		Revision as of 02:36, 22 July 2009
Line 48:		Line 48:
	*# At fourth/project level on CEB Press category page: '''Main -> Packages -> Habitat -> CEB Press'''		*# At fourth/project level on CEB Press category page: '''Main -> Packages -> Habitat -> CEB Press'''
	*# For all documents under the CEB press category this last header would be used, obviously not meaning to be exclusive of subcategories.		*# For all documents under the CEB press category this last header would be used, obviously not meaning to be exclusive of subcategories.
			----
			# This is very good! Time to make some changes and see how it looks.
			# I started to make some header templates for the Wiki category pages.
			#* The first thing I noticed was that Wiki needs a top-level supercategory Other. Something like this has to be done.
			#* I've added a [[Using header templates\|page describing the header templates]].
			# If you'd like to put together a top-down skeleton category structure, go ahead. I tend to think this needs to be approached from the bottom up.

Geoff at 00:33, 22 July 2009

2009-07-22T00:33:01Z

← Older revision		Revision as of 00:33, 22 July 2009
Line 37:		Line 37:
	#* There can be more than one way to navigate to a particular page (although the breadcrumb menu will show the one, "official" path)		#* There can be more than one way to navigate to a particular page (although the breadcrumb menu will show the one, "official" path)
	# I'm OK with breadcrumbs only, and no forward links, on most pages, but I think that the category pages, Habitat for example, have to have the forward links somewhere on the page, and it might as well be in the header. The forward links need to be set off visually from the breadcrumbs, maybe on a second line.		# I'm OK with breadcrumbs only, and no forward links, on most pages, but I think that the category pages, Habitat for example, have to have the forward links somewhere on the page, and it might as well be in the header. The forward links need to be set off visually from the breadcrumbs, maybe on a second line.
			----
			* Packages is a difficult one to escape. They are also "domains" in a sense, but that loses the implication of being packages of tech solutions fitting within the particular domain. They are also "sub-systems" within the larger system of a community. I'm sure something will be suggested or come up along the way.
			* Your vision vs philosophy argument makes sense. I guess all philosophical references can be tied back to the original vision, so the category wouldn't be exclusive of such things (eg an entry discussing the ethical treatment of animals and arguments for free-range would fit under OSA, but also ties back to the vision for the whole operation, so would appear in both categories.)
			* I think the main thing to come up with at this stage is the skeleton of the category structure and general principles to guide a common theme for laying out the entries within categories. Enough to provide consistency across the pre-existing work as it's refactored, and to guide any new additions in future. If we say that all project specific documents should be tied back to the project category, rather than the package category for instance, then in addition to making navigation easier and reducing orphaned pages we also make any future refactoring easier. For example:
			** Do we want documents about steam engines tied back to the Energy package category? If we went that way we would have an energy package category page with potentially thousands of disparate entries without any organisation. If on the other hand it was determined that project-specific pages tied directly to their project category only, as much as possible, then it keeps the package category clean with mostly project category links and the few documents directly pertaining to the package category itself. So documents about energy in general might link directly to the energy package category.
			* Are the following examples on the right track for the different levels of organisation? The bit in parenths are forward links.
			*# At top level: '''Main (Factor e \| Packages \| Vision \| etc )'''
			*# At second level on packages category page: '''Main -> Packages (Habitat \| Agroecology \| Energy \| Flexible Industry \| Transport \| Other \| etc )'''
			*# At third/package level on habitat package category page: '''Main -> Packages -> Habitat (CEB Press \| Sawmill \| etc )'''
			*# At fourth/project level on CEB Press category page: '''Main -> Packages -> Habitat -> CEB Press'''
			*# For all documents under the CEB press category this last header would be used, obviously not meaning to be exclusive of subcategories.

Dan at 04:35, 21 July 2009

2009-07-21T04:35:52Z

← Older revision		Revision as of 04:35, 21 July 2009
Line 27:		Line 27:
	*** '''Main -> Packages -> Habitat: CEB, Living Machines, Modular Housing, Sawmill'''		*** '''Main -> Packages -> Habitat: CEB, Living Machines, Modular Housing, Sawmill'''
	** It would make sense to go with the former, as you'd only be seeing that header on the habitat category page anyway, but it will require some method of highlighting the main packages within the category page so they stand out from the crowd. Perhaps every package category page has an introduction that bullet points the primary projects and gives an idea of progress/state for each?		** It would make sense to go with the former, as you'd only be seeing that header on the habitat category page anyway, but it will require some method of highlighting the main packages within the category page so they stand out from the crowd. Perhaps every package category page has an introduction that bullet points the primary projects and gives an idea of progress/state for each?
			----
			# At some point we will run out of ideas, and it will be time to start editing. I don't think we're there yet (we're still coming up with better and better ideas).
			# I think there should be several top level categories, at least these
			#* Factor e (the physical location)
			#* Packages (I don't like the word, but I'm not sure what would be better)
			#* Vision (I like this better than Philosophy, which suggests the academic discipline)
			# It will be impossible to come up with a hierarchy of categories, in advance, which will work perfectly for all the current pages and whatever pages will be added in the future. Materials is a good example of this. We just have to make a good effort and expect to refactor it now and again.
			#* Pages can have more than one category
			#* There can be more than one way to navigate to a particular page (although the breadcrumb menu will show the one, "official" path)
			# I'm OK with breadcrumbs only, and no forward links, on most pages, but I think that the category pages, Habitat for example, have to have the forward links somewhere on the page, and it might as well be in the header. The forward links need to be set off visually from the breadcrumbs, maybe on a second line.

Geoff at 00:03, 21 July 2009

2009-07-21T00:03:32Z

← Older revision		Revision as of 00:03, 21 July 2009
Line 16:		Line 16:
	# I personally (and this is a matter of style, not acceptable vs. unacceptable) favor extreme minimalism as to headers. People come to a page to read the contents, not the header. I'd rather hide the information for other levels inside tooltips than make it visible all the time.		# I personally (and this is a matter of style, not acceptable vs. unacceptable) favor extreme minimalism as to headers. People come to a page to read the contents, not the header. I'd rather hide the information for other levels inside tooltips than make it visible all the time.
	# Think about what I've said here. If you're happy with your current example, go ahead and implement it. If I've convinced you of the value of minimalism, let's see if we can simplify it first.		# Think about what I've said here. If you're happy with your current example, go ahead and implement it. If I've convinced you of the value of minimalism, let's see if we can simplify it first.
			----
			* I agree that there is a lot that doesn't fit under the current package arrangement. There certainly needs to be a way of tying those things back into the overall navigation scheme. I'm not attached to anything I've presented, I was just aware that change was required, and usually the best way to decide how that change should progress is to get in there and start changing things, or presenting examples of what change might look like. That way we get an idea of what will and wont work, and what other things need to be considering within the changes.
			* Where to from this point?
			** How can the whole be divided up into segments that will make sense to visitors, and keep the information arranged logically?
			** Would it make sense to have two (or more) top level domains, e.g. Philosophy and Practicality, or something along those lines?
			** There will be generic information (refer current [[:Category:Materials]] category) that is generically useful across different packages, and currently doesn't seem to placed firmly within a package. I think there are a few like this where they need to be drawn into one of the existing packages (flex industry for materials for e.g.) or consider creating new sections. Most of materials could go under a resource extraction and recycling project/package within flex industry.
			** I like the idea of breadcrumb style headers. Are you also thinking we would be better doing away with any forward links?
			*** '''Main -> Packages -> Habitat'''
			*** rather than:
			*** '''Main -> Packages -> Habitat: CEB, Living Machines, Modular Housing, Sawmill'''
			** It would make sense to go with the former, as you'd only be seeing that header on the habitat category page anyway, but it will require some method of highlighting the main packages within the category page so they stand out from the crowd. Perhaps every package category page has an introduction that bullet points the primary projects and gives an idea of progress/state for each?

Dan at 05:36, 20 July 2009

2009-07-20T05:36:35Z

← Older revision		Revision as of 05:36, 20 July 2009
Line 10:		Line 10:

	* I've modified the project header for habitat to include the site header directly, that way people only need to include the project header and the other one is included by default. Also removed the seemingly redundant "Packages" from the beginning of the package only content, as the site header above seems to qualify that enough. Check out [[:Category:Habitat]] to see if it's headed in an acceptable direction.		* I've modified the project header for habitat to include the site header directly, that way people only need to include the project header and the other one is included by default. Also removed the seemingly redundant "Packages" from the beginning of the package only content, as the site header above seems to qualify that enough. Check out [[:Category:Habitat]] to see if it's headed in an acceptable direction.
			----
			# I see where you're going and I think it's a big improvement over what is presently in the wiki.
			# We've been talking about "site header" but it really isn't. A page like [[Evolve to freedom]] doesn't fit into any of the packages or projects. It really needs a header like: '''Main -> Vision -> Freedom'''. We might want a Sawmill category with a header like: '''Main -> Packages -> Habitat -> Sawmill'''.
			# I think your latest example works well for a 2-level hierarchy, but not so well for 3 or 4 levels.
			# I personally (and this is a matter of style, not acceptable vs. unacceptable) favor extreme minimalism as to headers. People come to a page to read the contents, not the header. I'd rather hide the information for other levels inside tooltips than make it visible all the time.
			# Think about what I've said here. If you're happy with your current example, go ahead and implement it. If I've convinced you of the value of minimalism, let's see if we can simplify it first.

Geoff at 02:42, 20 July 2009

2009-07-20T02:42:26Z

← Older revision		Revision as of 02:42, 20 July 2009
Line 8:		Line 8:
	----		----
	Agreed. The particular styles were in place to try and distinguish the packages from the whole array of projects in the original header. By breaking it down into a clean package only header and then subheaders for the projects the styling can be cleaned up and it should be easier to see what's going on.		Agreed. The particular styles were in place to try and distinguish the packages from the whole array of projects in the original header. By breaking it down into a clean package only header and then subheaders for the projects the styling can be cleaned up and it should be easier to see what's going on.

			* I've modified the project header for habitat to include the site header directly, that way people only need to include the project header and the other one is included by default. Also removed the seemingly redundant "Packages" from the beginning of the package only content, as the site header above seems to qualify that enough. Check out [[:Category:Habitat]] to see if it's headed in an acceptable direction.