Talk:Artist Home

From OpenSimulator

(Difference between revisions)
Jump to: navigation, search
(Cleaning up and reorganizing)
(Cleaning up and reorganizing)
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Strategy? ==
 
 
Considering this page is listed from the sidebar link "Content Creation" I feel like it's important for this page to not only discuss the component content types, but also introduce readers to the content creation process within OpenSim.
 
 
 
 
== Cleaning up and reorganizing ==
 
== Cleaning up and reorganizing ==
  
Line 15: Line 10:
  
 
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.
 
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 cotnent there is, the harder it is to reorganize. Apart from some added external links, there hasn't been a single update for years. -- Tess Juel
+
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 (Content Creation)|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
 +
 
 +
You may be right that it would have been better to draft pages and publish when finished but then I wouldn't have had your feedback. I'm not joking, your comments here really helped a lot!
 +
 
 +
The way I saw it, and still see it, the original page was so barebones and outdated it wasn't really a functional resource at all so effectively taking it down for a few days wouldn't do any harm. I haven't seen the visitor stats but I wouldn't at all be surprised if you and I were the only people visiting the page during the resturcturing process.
 +
 
 +
In any case, the restructuring work is all but done now and it's done the way you last suggested. As I said in my first comment here, I wasn't really convinced my original scheme was a good one and it turned out it wasn't. I'll do a final check of the new pages and add backlinks to the main page. I've double and triple checked an am fairly sure I included all the content from the old page (except for outdated info and broken links of course) but if I missed something, it can be retrieved from the page history.
 +
 
 +
The content creation section of the wiki is still barebones with lots and lots of holes to fill in. But there's easily more than twice as much content as it was a week ago, certainly enough to show why it was necessary to split the page.
 +
 
 +
-- Tess Juel
 +
 
 +
 
 +
Trying a style for Sounds, Music, Media : A short lead with definitions, disambiguation, mentioning overlaps. Then branching to the detailed pages. Tell me if you like it. -- JeffKelley
 +
 
 +
 
 +
Great idea but I would have put this on the Sound (Content Creation) page.
 +
 
 +
One reason is page length. Right now the page's word count is 323, the file size (not including images etc.) is 32.1 KB and the page requires one click on the scroll bar to get to the end on a standard HD monitor. Ideally those numbers should not exceed 1000, 100 and 3 respectively so we're not anywhere near the limits yet. We almost certainly will be when all topics listed on the page have been edited the same way though.
 +
 
 +
Another reason is search engine ranking. Google and Bing are far more likely to rank a page focused on a single topic (such as mesh, sounds, etc.) high than one that covers them all.
 +
 
 +
The good argument for keeping a  lot of content on a single page is of course that it saves visitors from clicking through multiple links. But in this case it's only a single link and they'll have to click on the scroll bar or the internal page index links anyway so I don't think it's relevant.
 +
 
 +
--- 2023-06-03 Tess Juel
 +
 
 +
 
 +
 
 +
> Great idea but I would have put this on the Sound (Content Creation) page.
 +
 
 +
Definitely no, because « Sounds clips can be used within (scripted) objects and as part of gestures ». Sounds, Music and Media are different things with overlapping usage (You can play music with '''Music''', but also with '''Media'''. There are also ppl who play music chaining 10s '''Sounds''', which is a terrible idea). So, the need for a short explanation giving enough information to choose one of three ways.
 +
 
 +
-- JeffKelley
 +
 
 +
----
 +
 
 +
I have models to build, textures to create and a lovely RL garden to tend and enjoy. In other words: Life's too short for wiki editing wars. I've returned everything back to how it was before I started editing.
 +
 
 +
Edit: To clarify, I don't mind if the wiki uses my contributions here but only if other people actually want it. Feel free to reinstate my edits if you like, or not if you don't. I don't care.
 +
 
 +
-- Tess

Latest revision as of 22:11, 3 June 2023

[edit] 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

You may be right that it would have been better to draft pages and publish when finished but then I wouldn't have had your feedback. I'm not joking, your comments here really helped a lot!

The way I saw it, and still see it, the original page was so barebones and outdated it wasn't really a functional resource at all so effectively taking it down for a few days wouldn't do any harm. I haven't seen the visitor stats but I wouldn't at all be surprised if you and I were the only people visiting the page during the resturcturing process.

In any case, the restructuring work is all but done now and it's done the way you last suggested. As I said in my first comment here, I wasn't really convinced my original scheme was a good one and it turned out it wasn't. I'll do a final check of the new pages and add backlinks to the main page. I've double and triple checked an am fairly sure I included all the content from the old page (except for outdated info and broken links of course) but if I missed something, it can be retrieved from the page history.

The content creation section of the wiki is still barebones with lots and lots of holes to fill in. But there's easily more than twice as much content as it was a week ago, certainly enough to show why it was necessary to split the page.

-- Tess Juel


Trying a style for Sounds, Music, Media : A short lead with definitions, disambiguation, mentioning overlaps. Then branching to the detailed pages. Tell me if you like it. -- JeffKelley


Great idea but I would have put this on the Sound (Content Creation) page.

One reason is page length. Right now the page's word count is 323, the file size (not including images etc.) is 32.1 KB and the page requires one click on the scroll bar to get to the end on a standard HD monitor. Ideally those numbers should not exceed 1000, 100 and 3 respectively so we're not anywhere near the limits yet. We almost certainly will be when all topics listed on the page have been edited the same way though.

Another reason is search engine ranking. Google and Bing are far more likely to rank a page focused on a single topic (such as mesh, sounds, etc.) high than one that covers them all.

The good argument for keeping a lot of content on a single page is of course that it saves visitors from clicking through multiple links. But in this case it's only a single link and they'll have to click on the scroll bar or the internal page index links anyway so I don't think it's relevant.

--- 2023-06-03 Tess Juel


> Great idea but I would have put this on the Sound (Content Creation) page.

Definitely no, because « Sounds clips can be used within (scripted) objects and as part of gestures ». Sounds, Music and Media are different things with overlapping usage (You can play music with Music, but also with Media. There are also ppl who play music chaining 10s Sounds, which is a terrible idea). So, the need for a short explanation giving enough information to choose one of three ways.

-- JeffKelley


I have models to build, textures to create and a lovely RL garden to tend and enjoy. In other words: Life's too short for wiki editing wars. I've returned everything back to how it was before I started editing.

Edit: To clarify, I don't mind if the wiki uses my contributions here but only if other people actually want it. Feel free to reinstate my edits if you like, or not if you don't. I don't care.

-- Tess

Personal tools
General
About This Wiki