Suggestions Requested

I'm working on the next chature of my sheet blog's author guide, and it's about the things you need to know that aren't specifically coding HTML, CSS&lt; or javascript. Here's the current list of topics. Are there any topics I've missed or you think would be good additions: The Custom Sheet Sandbox: The best tool Roll20 provides for making your sheets. Using a Syntax-Aware Code Editor: get error checking and syntax help as you write. Validating Your Sheet: How to find errors in your sheet (and why you shouldn't trust Roll20's built-in preview) Inspect Browser : Every modern browser has a built-in feature which lets you examine a sheet, and you can see why code isn't working properly. This is amazingly useful for CSS and Sheet Workers. Using Github: how to upload your sheet to the Roll20 sheet repository, and update your sheets. Sheet Images: How to handle custom images in your sheet, and avoid missing images errors. JSON Properties: Add custom properties to your Sheet, and what they even are. And most importantly, make sure you are not using Legacy Sanitization (and what that is). The blog is here: <a href="https://cybersphere.me/" rel="nofollow">https://cybersphere.me/</a>

Maybe something covering Character Sheet "Oddities"?&nbsp; Strange behavior or broken functions due to odd quirks or bugs.&nbsp; Off the top of my head: naming rules for repeating sections and action buttons. Action buttons that fail to trigger sheetworkers if they are inside a relative or absolute html element. Tables inside repeating sections also causing event issues.&nbsp; More: <a href="https://wiki.roll20.net/Character_Sheet_Development/Bugs_%26_Quirks" rel="nofollow">https://wiki.roll20.net/Character_Sheet_Development/Bugs_%26_Quirks</a>

Good suggestions, but I'll keep them for the chapters where they are relevant. I do have a plan to do a "chapter" focussed on sheet workers, another on repeating sections, etc. For this series, I'm looking for things that aren't specifically about coding, but the "meta-" aspect of sheet making - stuff you need that isn't actually directly related to creating a character sheet. Like uploading sheets to Github, the URLs to use for sheet images and pitfalls if you don't put them on the github repo, and things like that, I also have a very strong suggestion in the HTML chapter not to use tables at all, so I don't know if there'll be a place to mention that one. I plan to only show code that will be accepted by Roll20, and tables won't. I definitely need to have a longer look at that oddities page. There's a couple of things I'd overlooked (like the optgroups not working in custom sheets - I do mention it but forgot to include a fix for it, assuming that people would share their sheets and not keep using a custom sheet).

Maybe address how best to approach editing an existing community sheet by either working with an active author or stepping in when a sheet is no longer being maintained by someone?&nbsp; How to contact the sheet author listed in the sheet.json, perhaps making a public announcement on the character sheet &amp; compendium forum and/or adding a note to the sheet of proposed changes with a link back to the forum sheet thread.&nbsp; Perhaps creating a publicly accessible test game to try out features and solicit the suggestions/feedback.&nbsp; Kind of the socially polite way to make changes to a public sheet. ;-)

Those are really good suggestions

How about addressing some accessibility topics like contrast/legibility, whether to translate or not to translate the sheet, and/or ways to make migration easier?

Accessibility is definitely a good idea. Translation has a chapter planned, but your phrasing makes me curious: are there situations you would expect me to recommend not translating a sheet? The only times I can think of that being a good idea is for a sheet you have no plans to share with anyone else (or if you just don't know how to and don't have the time). What do you mean about making migrations easier? Are you talkin about duffeernt sheets for the same system? This suggestion does make me think about giving advance for attribute names, is there something else you're getting at?

GiGs said: Translation has a chapter planned, but your phrasing makes me curious: are there situations you would expect me to recommend not translating a sheet? The only times I can think of that being a good idea is for a sheet you have no plans to share with anyone else (or if you just don't know how to and don't have the time). That's the only time I can think of, personally. I suppose there could be other scenarios, but I can't think of any. &nbsp;However, this could help reinforce that if you intend to upload the sheet for community use, then do the data-i18n stuff. GiGs said: What do you mean about making migrations easier? Are you talkin about duffeernt sheets for the same system? This suggestion does make me think about giving advance for attribute names, is there something else you're getting at? Yeah, I was thinking about different sheets for the same system. I realize this isn't much of a thing any longer, but could be. For example, Forbidden Lands, Coriolis, Mutant Year Zero all use the same engine; while not likely, it is conceivable that a person may want to use one character in one of the different settings so if you plan appropriately, you could port that character over with minimal data loss (given that there are differences, I would also set the expectation that unless they all use the same sheet to change views, data loss is going to happen, so this would be about minimizing that). Something else that may be worth considering is in-game sheet configuration and whether that's needed or not. &nbsp;For example, WoD has different settings that all exist in the same game world (Vampire, Werewolf, etc) and we see a lot of people requesting a combined sheet; this would be doable with an in-game configuration capability. I bring this up here, because it almost falls into two different categories: actual sheet coding, but also part of the "meta-" aspect in terms of "planning" your sheet before you start. &nbsp;Knowing you want something like this from the start allows you to make the necessary changes at the right time rather than having to go back in and fit it in somehow. I think most of my problems come from a lack of sheet planning (which also goes for sheet workers), whereas I could have saved myself a lot of hassle if I'd simply thought about what features the sheet needed before I did anything.

Finderski said: That's the only time I can think of, personally. I suppose there could be other scenarios, but I can't think of any. &nbsp;However, this could help reinforce that if you intend to upload the sheet for community use, then do the data-i18n stuff. So far, I haven't done anything that was printed in any language other than english, so I feel comfortable leaving it out.&nbsp; I suppose including translations does "future proof" against that changing though.

Kraynic said: So far, I haven't done anything that was printed in any language other than english, so I feel comfortable leaving it out.&nbsp; I suppose including translations does "future proof" against that changing though. It is good advice to include translations in all sheets that you plan to share. That makes those sheets available non-English speaking players. Perosnally I understand not doing it - it's a lot of extra work. But it's still good advice to suggest doing it.

Finderski said: GiGs said: Translation has a chapter planned, but your phrasing makes me curious: are there situations you would expect me to recommend not translating a sheet? The only times I can think of that being a good idea is for a sheet you have no plans to share with anyone else (or if you just don't know how to and don't have the time). That's the only time I can think of, personally. I suppose there could be other scenarios, but I can't think of any. &nbsp;However, this could help reinforce that if you intend to upload the sheet for community use, then do the data-i18n stuff. GiGs said: What do you mean about making migrations easier? Are you talkin about duffeernt sheets for the same system? This suggestion does make me think about giving advance for attribute names, is there something else you're getting at? Yeah, I was thinking about different sheets for the same system. I realize this isn't much of a thing any longer, but could be. For example, Forbidden Lands, Coriolis, Mutant Year Zero all use the same engine; while not likely, it is conceivable that a person may want to use one character in one of the different settings so if you plan appropriately, you could port that character over with minimal data loss (given that there are differences, I would also set the expectation that unless they all use the same sheet to change views, data loss is going to happen, so this would be about minimizing that). Something else that may be worth considering is in-game sheet configuration and whether that's needed or not. &nbsp;For example, WoD has different settings that all exist in the same game world (Vampire, Werewolf, etc) and we see a lot of people requesting a combined sheet; this would be doable with an in-game configuration capability. I bring this up here, because it almost falls into two different categories: actual sheet coding, but also part of the "meta-" aspect in terms of "planning" your sheet before you start. &nbsp;Knowing you want something like this from the start allows you to make the necessary changes at the right time rather than having to go back in and fit it in somehow. I think most of my problems come from a lack of sheet planning (which also goes for sheet workers), whereas I could have saved myself a lot of hassle if I'd simply thought about what features the sheet needed before I did anything. I'm definitely suggesting in-game configuration - I have a part on JSON Properties where that will be covered. That said, it doesn't have to be in JSON properties. I do need to talk about the more extensive changes like ther WOD sheet - having multiple sheets in the same sheet, effectively. Regarding Coriolis, MutantX, etc - just for curiosity, do they all use the same attributes and supporting attributes (like hit points, saves, and whatever)? In my experience characters in games by the same publisher using the same engine are still incompatible with each other (White Wolf being an exception), because they each change the system a bit.

GiGs said: Regarding Coriolis, MutantX, etc - just for curiosity, do they all use the same attributes and supporting attributes (like hit points, saves, and whatever)? In my experience characters in games by the same publisher using the same engine are still incompatible with each other (White Wolf being an exception), because they each change the system a bit. There are differences, but the core stats remain the same (may be renamed for flavor...like Vaesen has the same core attributes, just called something different - but still meaning the same thing), as do most of the mechanics (such as HP, etc). An easier example would be Savage Worlds. &nbsp;If I weren't coding that to be usable by all the different settings, there could be different sheets for each setting and all those stats would remain the same.

Finderski said: GiGs said: Regarding Coriolis, MutantX, etc - just for curiosity, do they all use the same attributes and supporting attributes (like hit points, saves, and whatever)? In my experience characters in games by the same publisher using the same engine are still incompatible with each other (White Wolf being an exception), because they each change the system a bit. There are differences, but the core stats remain the same (may be renamed for flavor...like Vaesen has the same core attributes, just called something different - but still meaning the same thing), as do most of the mechanics (such as HP, etc). An easier example would be Savage Worlds. &nbsp;If I weren't coding that to be usable by all the different settings, there could be different sheets for each setting and all those stats would remain the same. That makes me think of games like HERO System and GURPS. But these (and savage Worlds) are the samge game with different "skins". The Fria Lignes and White Wolf games are a bit different - each game often has different features. I wonder if the guidance here should be how to build one master sheet that can be several different related games (like with the various Fria Ligens games, svaage world games, white wolf, etc), with the various attributes and graphics suitable for that particular sub-game? Actually migrating between completely separate sheets seems like a nightmare on Roll20 unless all the sheets were being made by a single person/team with that in mind from the start.

GiGs said: That makes me think of games like HERO System and GURPS. But these (and savage Worlds) are the samge game with different "skins".&nbsp; You'd think that, and then you'd run into Savage Worlds Rifts. LOL Actually, many of the Savage Worlds settings make slight tweaks to the game (adding additional derived stats, etc), but I understand what you mean. 😀 I only mentioned it, because I've see people using one sheet for a game and then wanting to use a different sheet but keep the character. Really, D&amp;D could have benefited from people thinking about things a little before hand (heck, even Savage Worlds...it wasn't something I thought about when I wrote the Tabbed sheet). If people who made D&amp;D sheets after the first one was made would have used the same attribute names as much as possible (allowing for differences where some sheets may use fewer or more attributes depending on desired functionality) migrating from one D&amp;D sheet to another could be done and keep the core attributes, class, level, etc in tact. &nbsp;If I was going from the D&amp;D 2e to 5e there would be manual tweaks I'd have to make, but my 15 strength and 6 intelligence would have all transferred over without a problem. &nbsp; I recognize this also would be a lot more work than a person may want to do, but...it's a consideration. And I totally understand why you may not want to include something like this in your series. My main goal was to throw stuff out there and see if it shakes any other ideas/thoughts loose. LOL

Finderski said: And I totally understand why you may not want to include something like this in your series. My main goal was to throw stuff out there and see if it shakes any other ideas/thoughts loose. LOL I can mention it as a consideration, but I think it's mostly impractical to have to do it. That said, I have considered changing attribute names in my homebrew Pendragon sheet (my first sheet, which I still use) to match the available community sheet, for easier migration. So it's not impossible if working with variant sheets for a game.