Talk:Artist Home

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
m (Correcting typos)
Line 30: Line 30:
  
 
One thing I'm not happy about with the formatting is that level 3 and 4 headers look very similar so it's hard to see the difference at a glance. I'm tempted to skip level 4 headers and go straight from 3 to 5. -- Tess Juel
 
One thing I'm not happy about with the formatting is that level 3 and 4 headers look very similar so it's hard to see the difference at a glance. I'm tempted to skip level 4 headers and go straight from 3 to 5. -- Tess Juel
 +
 +
 +
 +
I did not say yet that it's better to keep the original structure by asset type, although yes, this would have my preference. What I'm voicing here is that you are disrupting access to the information for a undetermined amount of time by working on a live (which ppl browse now) dataset, what you could easily avoid working on a copy.
 +
 +
Structuring by Best Practices/Guides/Tutorials/etc seems secondary to me. If it was harmless in the monolithic page, it now creates a maze in the structured version.
 +
 +
Let's see the experience of a visitor looking informations about meshes, today. He is greeted with a single link page, and the linked page conflates meshes and prims with just one link about meshes (How To Upload Mesh). Path to tools is lost, unless he backtracks two steps and ask for Tools. Better give him all informations pertaining to meshes when he clicks on Meshes. My opinion.
 +
 +
Also, the hierarchy (as implied by indentation) models = prims + sculpts + meshes makes few sense. Clicking Models leads to How To Upload Mesh, but clicking on Meshes don't ! Maze again. I think we can safely assume model IS mesh, and drop 'models' forever.
 +
 +
To summarize my thoughts : Break into asset types, give all infomation for this type on a single page (no maze), keeping loosely the Practices/Guides/Tutorials/etc framework.
 +
 +
-- JeffKelley

Revision as of 01:53, 29 May 2023

Cleaning up and reorganizing

I'm trying to come up with a new structure for the Content Creation part of the wiki and I think it needs to be split up into several pages to make room for more content. I'm not quite sure how to do it though, there are two options:

  1. One page for each type of info (Guides, Tools, Content Libraries etc.) with subsection/pages for each asset type
  2. One page for each asset type with subsection/pages for each type of info

I've gone for option 1 for now but that can be changed if people feel #2 is better. We can of course also have both by adding list pages for both options.


Why not leaving the last monolithic version of the page untouched and working on a copy until there is more substance ? The current version links to a lot of empty pages , and informations that were present on the old page are now orphaned until you port them to the new structure, which can take a long time . Also, you are erasing memories (« There was something about How To Upload Mesh here yesterday, where is it gone now ? ») . Please consider restoring revision 53311 and working on a draft without breaking existing content. -- JeffKelley

Woops, the link to the How to upload mesh page got lost. Sorry, I'll fix that. Nothing else of the original content should be missing though, except for broken links of course but we don't want them here. The reason why I split up the page right away is that I hope we can get the work on the section (re)started asap and the more content there is, the harder it is to reorganize. Apart from some added external links, there has hardly been a single update for years.

Edit: About the many empty pages, I was going to add content to most of them today but it'll have to wait because the werver is horrendously slow at the moment. I did manage to add that link that went AWOL though. -- Tess Juel


What if your are prevented to proceed for any reason (internet outage for example) ? The wiki is in an inconsistent state for the time you are oway. Build new before scratching old should be the rule. It applies to code as well as documentation. We make a new branch then merge it with the main when the new code is satisfactory. Here, merging is nothing more than copy/pasting the new page onto the old one, leaving no interim, unfinished state. If you don't want to restore the old version, at least link it from the new page so ppl are not lost. -- JeffKelley

That is a very good point but it was the case for the page before I edited it too. It consisted mainly of headers for sections that were never filled with any actual content.

There are really three different questions here:

  • How should the info here be organized to make the info as easy to find and understand as possible? That is an open question. I've already suggested two alternatives here and I'm sure there are others too.
  • How do we fill up the page(s) with the information needed? I don't really have an answer to that and nor does anybody else it seems. I'll try to do my part but we need far more contributor than we have had so far.
  • When should the info be split into several pages? I think the answer is as soon as possible because, as I said earlier, the more content there is to sort, the harder it becomes. The good old builder rule make the structure first, then fill in the details, applies as much to a webstie as to anything else we create. The content creator section of the wiki has to be split up into several pages, probably far more than what I've added, at some point if it's going to become a useful resource for content creators. There is simply far too much information that should be added for it to fit a single page. Of course, there's a good (I mean bad) chance nobody will ever get around to fill in all that information but in that case, this will never be a useful resource anyway so it won't really matter how it's organized.

-- Tess Juel

I've been thinking a bit more about the organsation of the content here. I'm still convinced that the original single page needs to be split up now rather than later but I do agree with what JeffKelley seemed to imply but didn't outright: it's better to keep the original structure with asset type (model, texture etc.) as the main sorting factor and content type (guide, tools etc.) as the secondary so I'm changing it back to that.

Edit: I have re-formatted the prims page as a test/demo. Any comments and suggestions for improvements are appreciated. I've included all the section implied in the original Artist Home page plus two more (Documentation and Tutorials) as subsections under a links section since it seems that was what they were all about.

One thing I'm not happy about with the formatting is that level 3 and 4 headers look very similar so it's hard to see the difference at a glance. I'm tempted to skip level 4 headers and go straight from 3 to 5. -- Tess Juel


I did not say yet that it's better to keep the original structure by asset type, although yes, this would have my preference. What I'm voicing here is that you are disrupting access to the information for a undetermined amount of time by working on a live (which ppl browse now) dataset, what you could easily avoid working on a copy.

Structuring by Best Practices/Guides/Tutorials/etc seems secondary to me. If it was harmless in the monolithic page, it now creates a maze in the structured version.

Let's see the experience of a visitor looking informations about meshes, today. He is greeted with a single link page, and the linked page conflates meshes and prims with just one link about meshes (How To Upload Mesh). Path to tools is lost, unless he backtracks two steps and ask for Tools. Better give him all informations pertaining to meshes when he clicks on Meshes. My opinion.

Also, the hierarchy (as implied by indentation) models = prims + sculpts + meshes makes few sense. Clicking Models leads to How To Upload Mesh, but clicking on Meshes don't ! Maze again. I think we can safely assume model IS mesh, and drop 'models' forever.

To summarize my thoughts : Break into asset types, give all infomation for this type on a single page (no maze), keeping loosely the Practices/Guides/Tutorials/etc framework.

-- JeffKelley

Personal tools
General
About This Wiki