skinsort

[skinsort]

Grid skin underway, courtesy of insomnia lol. One piece at a time, or the whole skin all at once and then tutorials? The problem here is even though I have a fairly developed idea, minds change. I might make the banner/nav, love it, and then finish everything else and redo the first three things I worked on because they're suddenly hideous or I uncovered a preferable approach halfway through. Hm. Despite the delays, I think one skin all at once is most practical? The cleanest css/code is possible that way, probably. Maybe some like idk, explainer for how things get consolidated in a stylesheet along the way? Also do people want features beyond the skin itself, like my auto claim stuff, or free to use resources ala fizzy elf's memberlist stuff, etc? or is that kind of add on so ubiquitous there's no need? Genuinely don't know what code the wider rpc has cracked with that stuff.

[skinsort]

I appreciate the ask, but no I will not be turning anon asks on lol. I promise I don't bite, good faith questions will always get good faith answers. I didn't have tumblr for about 7 years between the mid aughts and deciding to admin again last year, but in ye olden days I never saw anon askboxes turn out particularly well for people. I'm more inclined to just publish answers and leave askers anonymous anyway, so if that's your preference, feel free to just let me know in the ask itself, I assumed you would in this case! Just be polite and everything will be fine, I promise!

[skinsort]

I've been thinking about how to teach responsiveness and surprise surprise, complicated topic is complicated. I think the best move is to code a couple free bases using different approaches. One with grid, one with flexbox, one with percentage. I could write up some explainers for each element to help make it useful for people trying to learn. Probably gonna make a kofi or smth though, that's a lot of work, but the most useful thing I can think to do tbh. Open to thoughts on this lol.

[skinsort]

Hello, I've been thinking about code and selling code and sharing code in the rpc because someone posed the question to me of what I'd want to happen if someone was heavily editing a skin I sold, and to be honest, my first instinct was 'take my name off it'. That was met with some surprise, but let me explain why.

Code, to me, is a largely democratic landscape. If you want to learn, hundreds of thousands of people and websites have come together to teach you. Masses of people share open source work on codepen, stack overflow etc. Code as a skill is like assembling an especially abstract puzzle where you can only think about the pieces, not really see them. But most puzzles have similar strategies to solve- start with the corner pieces, then the edges, then the most recognizable patterns etc etc etc working your way down to the more and more difficult details. Most of code- most of my job writing code- involves minimizing the amount of time working on those shared strategies so we can have more time to work on the the interesting bits, the hard bits. the bits that make the site we're working on unique and useful. Frankly, jcink is the easy part of code, by and large. Your data is already structured and provided to you in a very particular way. It is inefficiently, but largely documented. Many other people have solved all the problems you are likely to have trying to build a skin. Skinning is html and css for the vast majority of items. It is the easy stuff. If I sell code, that code is now the property of the person I sold it to. It is not shareable or redistributable. You can't take my code and resell it as your own, but as far as I'm concerned you can do whatever you want with it. If I solved problems that might otherwise feel difficult (accessibility and responsiveness come to mind) cool. You can solve the easy ones, like styling and colors and fonts you like. You can add or subtract things that vibe with what you want that code to do. Once it is sold, it is yours to do with what you like when it comes to personal use. This is true of almost all coding contracts that exist in the entire world. If it weren't, no one would ever hire external contractors to do any work for their company, and I can tell you now, even companies which could fully afford to do all their tech in house absolutely do not in 99% of cases if their business isn't selling their own tech. The rule is generally- you may do anything you like with this, except resell it to someone else. So why take my name off it? I don't endorse how other people code. Even in my professional life, I've taken projects off my portfolio because the client took a project I worked on and broke it (imo), often with other professional developers doing the breaking. If a prospective employer were to go look at it, I'd be embarrassed by what it looks like today. Tell me why I (and my team) created a website that was fully responsive, and they went back to make it adaptive in the year of our lord 2022 because they preferred to have pixel perfect views at 3 specific breakpoints rather than a responsive site. I don't know, it's infuriating. I can't cite that project as an example of my work anymore, because it isn't. I would never leave a site in that state.

So, my first instinct with the idea of people using a skin i sell them as a base is 'take my name off it.' I don't want to be associated if responsive/accessible features are lost due to others working on a skin I wrote. But at the same time, where is the line between using something as a base, and editing a few small features? I certainly don't want to be an arbiter of that, or have to field questions or navigate feelings about it. In fact, personally I would not feel upset at all if someone used a paid for skin as a base, and inviting that kind of discussion is the only way I possibly could get upset since people have weird attitudes about a lot of this stuff. So I think the more practical standard is just to put credit, but make it explicit that the work has been heavily altered. Don't resell or redistribute, and you're golden, imo. Anyway, those are my feelings as someone who writes code for a living. I'm interested to hear counterpoints - constructively of course.

[skinsort]

Look, you don't have to do everything in code from scratch. It's fine to use generators to make your grid layout, or use scss to css converters to keep your stylesheets neater. As long as people have put a tool out there for the public to use, take free and full advantage. Most of the ethos in actual coding circles is in favor of open source- we none of us are doing anything truly original, unless we're writing a new language or framework from the ground up, which VERY few do. Even then, people want their tools to be used, and that's why they include examples, working sites, documentation, sometimes whole startup tools that will get you running a page in two commands. What matters on all sites it the actual CONTENT you put on a webpage, which is why all the most successful companies in the internet age rest on the foundation of what other people populate their sites with. netflix is nothing without creative film and television output, youtube is nothing without content creators, twitter, tiktok, facebook. even amazon doesn't mean anything if manufacturers don't sell their products there. All these sites are just wireframes for what YOU put on there. Do not shake in your boots about using freely disseminated code on the internet- stack overflow, open source repositories, design frameworks like bootstrap, material ui, free font packs, tutorials on code education websites, etc. Go, use it. People share these things with the intent of it all acting as a shortcut, usually without expectation of credit. They know that other people can figure this stuff out on their own eventually, their intent is to HELP. If a resource is open source, if a tool is available to the public, if a stranger answers a question on a coding help forum, I promise you. You can use it. There is no glory in making coding harder for yourself. Stand on the shoulders of coders who came before you. They wouldn't have put themselves there if they didn't want you to.

[skinsort]

Thank you to the suggestion(s) for resource sites, I've ported most of my codes over to moonlight, still open to hearing about any other options!

[skinsort]

Hello, if any of you have wandered here in the wake of caution closing, please know that you are very welcome to continue using any of my codes. Just swap the credit link to this tumblr account and you're good to go. Also if there are other resource sites out there for jcink, PLEASE let me know lol, I'm basically a grandma in the rpc and have no idea where else that kind of thing is being done.

[skinsort]

This will be of interest to only a few of you I'm sure, but I'm so used to the kanban style of doing things in code that I made my own system for skinning in Notion. Nitty gritty below the cut

The not started column is more or less in order of how I want to approach things- I find starting at the edges and working your way in is the best way to be able to get responsive coding right. My general process is first I get the view I want at a lager screen size- I have some intuition about how to structure things there so I'm not tearing my hair out later, I wish I knew how to articulate it better. I generally code things to be flexible from the start, so usually I need to start compensating when I've deliberately coded things to take up smaller than 100% widths of the view. At some point, having all the real estate in the screen will be critical- and that's usually where my breakpoint is. Secondly, I squish the screen in until things start to break. 600px seems to be my sweet spot for breakpoints. That's where 99% of my stuff was made responsive for Itero, and that's where my hero broke this time around too. I really try to keep to a single breakpoint- this often means simplifying structures as soon as a view gets that narrow, even if nothing has broken. Having things change across the site at different widths is a great way to get a headache.

When I finish an overall view (like the index, or a topic with all it's posts, etc) I'll do a sweep of all the common elements like colors and swap them to vars. I try to keep these segmented sensibly so that once I make a different mode, it's just a matter of swapping a few of those and not having to go bit by bit through the site making sure every swap looks good. I'm one of the few, the insane, the blue light lovers who really prefers a light skin, but I know I'm in the minority so I basically view a dark mode as obligatory.

Also for the curious, this is what my board looked like for my first skin.

I was interested in different things here. I wanted to guesstimate how long I thought things would take me, so I assigned a size to them, right at the beginning before I'd ever messed around in jcink. I was right about most of it, overestimated a few things, didn't underestimate at all, I think. I also was on a crunch towards the end as I was seized by the rabid desire to actually open a site, so I sorted my 'tickets' by tiers of necessity and put a lot of the most interesting problems on hold. Do people need a memberlist, or fun scroll animations for a site to be functional? As much as I hate it, the answer is the memberlist. No one is going to touch my css because I'm not selling itero, so I never went through and cleaned up after myself. As much as I really want to make a rule for topic descriptions so I can scrape all the threads on my board and generate a full timeline of everything that happens, that's an unreasonable ask for members. Some day I may go back and do some of this (especially the scrolling stuff), but like. Itero works. If I do more it'll probably be to beautify it, not any real structural or even functional change. Also, on the Modernity kanban board, I've got a field for tracking time which I'm going to try to be diligent about. While I've been able to pull a good deal of stuff to make jcink behave from my first skin (no one cares about you, news banner), I'm starting from scratch on the structure of the rest of it, so it should be representative of how much time a skin actually takes, from nothing, which I think should be interesting. Anyway, that's way too much writing about how I'm organizing my work as I approach a new skin. I hope this was useful, or at the very least interesting, and if not, thanks for reading to the end anyway, lol.

[skinsort]

Well I have no chill and spent like 6 hours on this today in lieu of anything useful. Basically I wanted to play around with transparency, gradients, and blurs, and much more abstractly a feeling of being kind of shoved through the skin a little bit with the italics and the off center layout. Most of that time was messing with extremely minute styling details. On the one hand I should probably fkin quit it with that, but on the other hand with something as abstract as the idea I had for this, spotchecking the feel as accurately as I can feels important. That feeling of driving through the skin is proving harder to make consistent, but I'm enjoying it all the same. I feel good about the hero and the navigation (aside from restyling John's dropdowns), they're responsive all the way through, but I have a ways to go yet on the categories and the forums obviously. I'm not sure I like them, but I think I have to finish the forum row first to see if the vision is good or just silly. If I don't like it, I know what the fallback is going to be at least (blur gradients, so many overlapping gradients).

If you code, I only really did one thing that might be new, and included the code for that below the cut.

The only real problem I solved so far was how to make the blur gradient spread across the entirety of the page, not just the view. I wanted the hero to be very clear, and everything behind the forums and stats to be blurry af so I can overlay text on them reasonably. Here's a little code snippet if you want to do a gradient similar that traverses the whole page (and not just the view height!). Put this in some script tags on your board wrappers. This basically listens to the page loading, or if someone resizes the screen, and then sets the height of the element that has the gradient on it- in this case blur-gradient. window.addEventListener('resize', setBlurHeight); $(document).ready(setBlurHeight)

function setBlurHeight() { const siteHeight = $(document).height(); $(".blur-gradient").css("height", siteHeight); } And here's the blur-gradient css:

.blur-gradient { backdrop-filter: blur(20px); -webkit-mask: linear-gradient(180deg, transparent, black 50%); position: absolute; z-index: -2; width: 100%; top: 0; bottom: 0; } blur-gradient itself is just an empty div with that class. It obviously doesn't have to be a blur gradient- you should be able to use this for any effect which you want to extend the whole vertical range of the page.

[skinsort]

Responsive vs. Adaptive vs. Neither of those things

Aight so. Big topic. We hear the word 'responsive' a lot when talking about web design but it's kind of a wishy washy topic for lots of people outside tech, especially if you've mostly coded while interacting with jcink. John did it really weird, with two skins- one for mobile, and one for desktop. This is actually pretty convenient because it helps distinguish two ideas. If you go to a website like youtube or even tumblr and resize your window as large as you can and as small as you can. These sites are properly responsive- the layout changes and adapts to the size of the screen. Youtube is (unsurprisingly) better at this than tumblr. It changes to use all of the available screen width at every size, pretty much no matter what. Tumblr (the dash anyway) only expands to a certain size- but it also doesn't break when you make it really small. Now go look at the base jcink skin- jcink support forums for instance. If you look at it on a phone, it'll mostly look okay, and after a certain size, will mostly look okay on desktop too. But there's this whole area between the two where things start to get janky. The fixed sizes of everything start to spill over the window size. That's an adaptive skin. Everything is a fixed size, and which layout you see depends on the type of device you're using. Adaptive sites are generally seen as outdated at this point. Almost no one is coding this way anymore. Now go to a jcink skin. Do the same thing with making your window bigger and smaller. In every skin I've ever seen, *something* will break. Text will overflow, you'll have to scroll from side to side to read a post, images will start to overlap other content. That kind of thing. Some sites will resize to a certain point, but almost none of them will do so all the way down to a mobile size, or even half of a laptop screen. This is neither adaptive nor responsive. THIS IS OKAY. I mean it's not ideal, but almost no one coding for jcink is a professional, and these are legitimately difficult things to get right. You have to be thinking about it from the start of the design process. What's going to happen to that icon when the screen gets small? What about the topic information? How are you going to keep information which looks beautiful at a desktop size looking good at tablet and phone sizes? It's legitimately difficult, and if you're not building with that in mind from the start it's a non-trivial task to make an unresponsive skin responsive. If you want to start thinking about these things, I'd recommend reading about media query breakpoints. For jcink, I think it's fair to code for desktop first (usually it's mobile first today) because people using a jcink site will usually want to be typing in it somewhere. Anecdotally, I think even people who post on mobile usually are writing in a notes app first. My skin worked really well at a 600px breakpoint, but other skins might need different figures. That's okay! As long as you can identify (maybe two) places where your views start to breakdown and have consistent behavior in your css for those breakpoints, you should be fine. I think it's good practice to know what you want your mobile version to look like, and code at least the skeleton of both views as you go, so you don't back yourself into corners. That's already a lot of text, so I'll stop there. I'll follow this up with a few different ways you can approach responsive design beyond breakpoints- grid, flexbox, and percentage based css. I can't really effectively teach these things on tumblr, but I can talk about the pros and cons of each approach so you can start looking into the things that seem like they might fit your use case.

[skinsort]

Selling Skins

My last post contained a lot of thoughts on skinning, the attitude towards coders in the rpc, and what we're actually paying for when we buy a skin. I kind of left it off with a so what, and a promise to talk more about my approach going forward. My thoughts on that are below.

Having made a completely original skin, and realizing how much time and effort it requires if I'm not doing derivative work every time, I also realized that doing customs makes no sense for me. There's no universe where that works out to be a reasonable use of my time- not just because the compensation is so far out of line with what I would normally charge for my skillset, but because I also wouldn't even be working on things I was necessarily interested in. I'm willing to discount my work to help the community in general- but only if I'm not treating it like an actual job, with clients telling me what to do and dictating the creative direction of my skinning. I don't want to deal with all that.

That said, there's some reasonable talk about what multisales and their value once they've been sold dozens of times. I think there's a sweet spot to be found there with limited multisales. Doing it that way allows a coder to make a reasonable amount of money in return for their time and skill, while also making sure that anyone who buys their skin won't be using it in an oversaturated field, full of other versions of the same thing. My plan moving forwards is to choose designs and new approaches which are interesting to me, fun for me to code, and likely different structurally each time. I probably won't be working off a base very often. I will be striving in every skin to deliver something which is (to me) a near-professional level of work- with responsive, intuitive accessible, performant designs. Because of this, I'll be pricing higher than most multisales. Most skins I see look very aesthetic at large screensizes, and simply don't function well in any other way. I can't code like that, it's simply not in my bones. So, given that, I will probably charge around $100 for a full skin, selling it up to ten times depending on the amount of time I spent on creating it. I will always fix any bugs which are found in a skin of mine, and I'll do a first time install for free. I think that's a situation which is most fair to everyone involved. There's a certain amount of uniqueness for the purchaser which doesn't require an exorbitant amount of money to commission me. I get to work on things I actually like and enjoy coding. I can hold myself to a standard I'm happy with in the work without drastically undervaluing myself or asking any one person to compensate me for that standard. Admins can actually afford a skin which rises to an high level on stuff that usually gets ignored. And if the way I code doesn't appeal, so be it, there's no butting heads over aesthetic preferences. I'll probably catch some flak for talking about my work this way, or pricing it along these lines, to which I can only shrug. I've worked in software development for a long time now on top of my education. I know what my time is worth, and I know how much I'm already giving away for free doing it this way. This is the structure I can feel good about, and I hope that as I start to release skins the people who purchase them feel like they got what they hoped and expected they would. If that doesn't seem to be the case I'll reevaluate- but honestly if I can't find a happy medium between using my time well and delivering a good product, I'll probably go back to just coding new skins as needed for myself. Anyway, those are my thoughts on how I'd like to balance providing a service and preserving my sanity as I start to skin for the rpc. I hope that makes a reasonable amount of sense to people, and I look forward to bring things live in the new year!

[skinsort]

I don't think I have a ton of followers, but for those who are here, below the cut is basically a very long think piece on jcink skinning that will probably offend a lot of people, but it's my honest take and I'm willing to hear other people's constructively expressed criticisms, and am very open to revising my opinion. I just was surprised by the SOPs I found in the jcink rpc when I started writing this skin and was doing research into whether I wanted to try selling it or not. For anyone wondering about the future the TLDR is as follows: I will probably make another skin and sell it as a multisale and see how that goes. This will probably happen a long time from now. I will probably never take custom commissions. I will probably charge more than people would like for my skins, but I think I have good reasons for that. More below the cut on the actual thoughts.

There were a few obstacles that became immediately obvious when beginning to work on a jcink skin for the first time.

First off, jcink is imo fundamentally bugged.

It has a slow initial load time even on the default skin, always over a second, usually over 2 in my testing. Industry standard is .5, and php (the backend language of jcink's templating system, and i assume the databases), though old, is perfectly capable of meeting that threshold. I personally find this an infuriating fact about jcink, especially since I can do nothing about it.

There are two distinct skins on any site by default, neither of which are responsive. Responsiveness basically refers to whether or not a website looks good regardless of screen size. It's a universal concern in any modern tech company. I understand that when jcink was first written, a lot of what's possible today wasn't available, however we are long since past the time (in my opinion) that it would have been simple for John to reskin the default view of jcink to be responsive and provide that as an alternative to the og defaults. If nothing else, this would provide a better standard for what a 'functional' skin might look like, and maybe even a baseline for people to build off of. Instead we have tables which are generally unusable in modern web design.

Jcink is also not terribly accessible by default. I found text labels missing in several places (for screen reader users), no keyboard accessibility on a few default functions (for people who can't use a mouse), and of course, nothing in the docs to remind people to keep what features there are in the default skin.

Then we have the added complications of the jcink rpc community, the skinners and coder in general within the space. I think I can break down my thoughts on this into three main categories: Price, Product, and People. I have a lot of thoughts about these topics, so bear with me.

Price

Look me in the eyes. Not one single skinner I could find was charging a market rate for front end web development. The most expensive person I could find wasn't even asking for 25% of the money a front end website developer would make for a skin professionally, and I found them because people were putting them on blast for charging as much as they did. The jcink rpc has been getting bargain basement prices on code for EVER, and seems to have NO concept of the time and complexity of writing actually good code.

I have mixed feelings on this.

I have not seen a professional grade skin in the wild, not once, not even my own. The css on my skin is sloppy. There are areas I got a serious case of the fuckits on and wrote some ugly code. There's at least one info page on my site that looks weird af on mobile and I have no intention of fixing it. I say this with love, compassion, and appreciation for everyone who codes for this community. Not one single jcink skin I have ever interacted with would constitute a professional level of work in my field. No one whose work I have interacted with (again, including my own!!) should be charging a fully professional rate.

This is a hobby. We do this for fun. We shouldn't be in an arms race for the prettiest skins, but we are. People like nice interfaces, it will affect their decision to consider or nope out of a site. So, we're in a situation that for a 'not boring' skin, custom skinning has become much more of a norm. In order to have a successful site, admins generally need to invest in a decent skin. With a custom skin, you can easily get to $250 in cost, and I've seen it go quite high from there. That's a lot of money for a site which may not survive. That's a big fuckin' deal. Some people are serial site starters so if one fails, that's fine, the skin can be reused, but I personally have not adminned a site since 2016 until a month ago. If I had sunk $250 into a skin, plus $80 for jcink premium for a site that never took off, suddenly my 'free' hobby becomes quite dear. I think it's only right that there be a certain degree of friendliness in the community when it comes to pricing because of this, even for truly professional coders (again, of which I've seen zero). Skinners are part of the ecosystem and deserve to be properly valued. Admins shouldn't have to pay out the ass just to have a better chance of their site taking off.

There's a great deal of risk involved in most skinning transactions I know of. First off, unlike the real world, we often don't know each other's irl identities. This makes a situation rife for scammers on both ends of the transaction- from skinners not getting paid for delivered work, and customers not getting the product they asked for, if they get it at all. This rightfully affects both parties' feelings on how to adjust pricing to account for risk. If you're a coder, prices should be higher, if you're an admin, prices should be lower. This has been more or less solved for multisales with payhip etc, but custom skins are still fraught, and in a world where plenty of players won't consider a site if they've seen the skin too much, that is still a significant chunk of the activity at play.

So do I think skinners should be paid fully professional rates? No. From what I have seen and learned, absolutely not. It didn't occur to me to track the time spent on my skin until quite late in the process, but if I had to guess I'd put it at about 40 hours worth of work. I'll talk more about this in the product section if that seems like a lot of time to you. I'll throw out a very loose figure and say that $50/hr is about right as a figure for what a professional developer would make doing this kind of work, after tax etc. If you're being responsible about the IRS, it would bump significantly higher. If you multiply that by the 40 hours I spent on my skin, we're getting into multiple thousands of dollars for a custom skin if people were charging professional rates. Now it's very possible that if I made skinning My Thing, that I'd build up a library of components I could pull on to make skins much more quickly. I know for a fact that many skinners do. But even if we say I halve my time on my second skin (optimistic but v possible), we're at $1000 if I was charging the prices I charge my employer to keep me on board. That is CLEARLY unsustainable for a hobby centric community where money never gets involved. So what should pricing look like? I really think that depends on the product.

Product

So. I think there's some room for honest reflection in jcink skinning communities about what is being sold. To contextualize this, I have to lay out the basics of what my general mindset is around what makes a website good for its users.

The obvious one, and the one that I think gets the most attention in jcink skinning is aesthetics. How a site looks, whether it's pretty, etc. I think this is important, I care about things looking good, but out of these five concerns, this one is frankly last on my list of what's important.

UX Design/Functionality. No, this is not the same as aesthetics. Is a site easy to understand, use and navigate. Does it make it seamless for a user to get where they want. Does it provide the contextual information they expect from the page they're visiting. These questions are fundamental for me, and I'd rather have a well designed user experience, than a well designed asethetic experience on a site.

Accessibility. Is a site readable. IS A SITE READABLE. IS A SITE READABLE. Is there enough contrast on a page that a colorblind user could read it? Can you navigate it with a keyboard? How about a screenreader? Is the text large enough for standard screen sizes. Does it stay large enough across devices?

Responsiveness. If someone on a phone visits my site, will they have a good experience in every view? Will they have the functionality they need? What about a tablet? What about someone with a small desktop screen, or a huge one? If I have hovers somewhere on my site, is it still navigable on mobile, or is it now an unintuitive situation? Phones take way longer to load than most computers, do all the assets (gifs, images, multiple fonts, etc) on my site make it frustrating for a mobile user to visit my pages?

Performance. When I said jcink is bugged earlier, performance was one my complaints. The base page load time of jcink is shitty. However, what's worse is when a skin takes a baseline of 2 seconds for pages to load, and bumps it up to 5, 8 or (the worst I've seen) 13 seconds to load after someone tries to visit a page. I have not seen a single jcink skin (aside from my own), which adds less than a second of loadtime to jcink's default performance. Again, in an industry where the basic standard is under half a second, jcink skins do not perform to a professional level.

If a website fails along these metrics, it cannot be considered professional for general public consumption. The problem is, everything except aesthetics requires a considerable baseline of knowledge and practice to do well. These are problems that many fortune 500 companies have not figured out (that's because their execs are dumb dinosaurs, but still). So when it comes to the question of 'how much should a skin cost', I think a skinner is obligated to consider their product. Is it aesthetically pleasing? Is it functional? Is it accessible? Is it responsive? Is it performant? For most skins, the answer to at least three of these questions is NO, and I think that pricing should reflect that. In my opinion, I think most skinners do well with asethetics, some skinners do well with functionality, and I have yet to see any truly accessible, responsive, or performant skins in the wild. When it came to writing mine, I think I needed about 5 hours to get familiar with how jcink worked, and then if I only wanted my site to look good on a desktop monitor, I probably could have spent 10-15 hours to write my skin as a noob having to look up every php variable John uses in jcink's terrible docs. That is not what I did. My skin is fully responsive, it is fully accessible, it is to my personal taste aesthetically, and is very performant (on average .25-.35 added seconds to my load time) despite having piles of functional scripts (all of which i wrote myself) on several pages. I also wrote several things that make my life and my member's lives easier. I have a member directory and face claim that require no work on my end past sorting an accepted character into the right member group. I have an autotracker built into member profiles so people can keep track of their threads. I have a button which allows members with lower end computers to turn off most graphics on the site so their computers don't sound like airplanes taking off. I have a light mode/dark mode switch that guests and members can both use. Personally, I would not feel like a freak for charging $1000 for a custom skin of this caliber. It's half what I would earn normally (using the $50/hr figure from earlier), and it lives up to all my standards for what professional code ought to do for its users vs. one or two. The css is not my best work, but I can say without undue arrogance that it's far and away easier to touch without breaking things than any other skin I've looked at, and the actual interface that people see and interact with is great. Again, the aesthetics are simple and to my taste, but it makes sense and has lots of quality of life bits and bobs in it. I'm proud of it. I understand if that entire paragraph read wildly, but I don't say any of it lightly or with the intention to belittle anyone. I'm trying to contextualize how I think about how price relates to what is actually being delivered. But even though I genuinely feel $1000 would be an excellent deal for the work I have done on my skin, I could not possibly stomach charging that much money to a single person for this skin, which (in addition to me using it on my own site) is why it is not going on sale.

To be honest, I have NO idea how much time a typical skinner spends on a custom skin. My approach is different from most people who do this for the community, and I also do adjacent work professionally and have for many years. I suspect that if asked to achieve all 5 of the above criteria, I would be able to do that significantly faster than most skinners. That said, I have no library of components I can turn to, and I hate a lot of the standard choices in building skins and would rather write my own. Isotope, cfs, etc can burn, they're bad code. There's tradeoffs to how I'd do things and how others would, which have significant impacts on time spent, but also on the outcome. Generally however, when it comes to jcink pricing, and how much people should charge or spend on a skin, I think the above 5 things should be the primary metrics. I made my own because I couldn't find a single skin that was truly accessible or responsive, and because I know how the sausage is made I simply couldn't stomach it. I can't really tell you how much you SHOULD pay for a skin that only does Aesthetics and Function, or only Function and Accessibility or any other combination. It's really not my place. I have thoughts on what I would charge, trying to be fair to myself and others if I were to make a multisale. But that's for a different post.

People

And then there's people. I touched on this earlier with some talk about scamming. I have heard horror stories on both ends of this interaction, and I think, simply speaking, it has created a lot of distrust around something which is a core decision for a lot of boards- which skinner to work with, what standards to set, how much things should cost, how to arrange payment. Payment structure has to take care of both you and the commissioner, but it also has to take into account that lots of people are gonna drive you up a wall, go ten rounds on their requirements, and then expect finished work two weeks after they finally got back to you about a core feature. With all due respect, clients who know NOTHING about tech and still have a lot of opinions on exactly how things should be done are my personal nightmare. I have not figured out any good way to account for this. I think custom commissions can be great for both the coder and the customer, but it's a total crapshoot as far as I can tell with no solve that I know of. I think there is also greater than average honesty and flexibility required from both parties in a non-professional setting(like jcink coding is) where money is still being exchanged. I think skinners have to be honest about their capabilities, their timeline, and how they want to work with customers. I think customers have to be honest about their expectations, their priorities and their consistency (are they going to change their mind frequently). I think both people need to be willing to find compromise. Since NO ONE is producing professional products and NO ONE is paying professional prices, there needs to be an understanding that sometimes things need to adjust. But, with custom skinning, it's often a lot of money for people. 250+ is a significant chunk of change. It feels wild to pay that much and not get exactly what you want. However, exactly what you want may be outside the skillset of a hobbyist, or it may simply be difficult or tedious or finicky, even for a professional. You want me to do custom svg clipping all over a skin? I'd rather die than do that during my free time. Furthermore, no skinner is being paid to do EVERYTHING that a professional site might demand. Being unhappy that you didn't get every concern addressed is not reasonable with the rates getting paid right now. There's ground to give on both sides. Flexibility is key, and it gets hard when there's money on the line.

Okay but so what?

Bish i don't know!!! Skinning is difficult niche stuff, especially if you're actually meeting any kind of professional standard. It's really easy to do badly. Paying for products where there is literally no professional available is always complicated. Idk what to tell you man. I'm just saying that I don't think anyone is getting paid a rate they deserve relative to the time they put in (probably), and simultaneously people don't get a product that lives up to the rest of the web right now because there's no real industry level professionalism available. And what's worst is that it's nobody's fault!! It's a tough spot to be in as a community! As for me, I'll probably do multisales in the future, and I'll probably charge significantly more than others because I'll be delivering significantly more. I am simply incapable of coding something that isn't responsive and accessible and performant if I'm going to charge money for it. It simply shan't happen, which means my time and skill will be reflected in the work and ergo the price. As for commissions, other people's taste irritates me too much to willingly get into typical freelancing in any capacity (affectionately, i will never be doing certain aesthetics unless people are willing to pay me my full rate, which no one should lol). I will almost certainly never do fully custom commission work. It is simultaneously not worth my time to do it for the rates offered by the jcink rpc, and it's not worth a commissioners money to pay for my skills when people are well used to skins that don't rise to professional standards anyway. Since I've finished my skin I've started posting some of the scripts I whipped up on caution. You can scroll back in this blog and find some of them. I'll probably continue to do that with anything I think another skinner could use. I will probably also start posting tutorials for discrete components so people have some examples of what responsive coding looks like. It's a tough nut to crack if you've never seen it up close before! If I'm really going to be a good member of the community I should probably start posting those here too more regularly. I basically just really want to help people out with their coding and contribute to the overall health of jcink skinning without undervaluing myself or gatekeeping good code. I will probably post my thoughts on how I'll be structuring the pricing for upcoming work in the next week or so. Expect updates after the holidays on upcoming skin ideas. Most of them have to do with implementing fun design stuff I never get to do at work- parallax effects, color manipulations, funky shapes, abusing css filter rules. I'd love to hear what kinds of things people would be excited to see first!

[skinsort]

I posted a tutorial which is basically css 101, stripped back to the stuff that I think is most helpful for jcink coders. You can take a look here. I hope this serves as a good reference/learning tool.

[skinsort]

Thread Autotracker

I wrote an autotracker a couple years ago and I think it's generally speaking super useful. You can see it here. The instructions and troubleshooting has been extensively added to and made clearer over time on caution, I highly recommend using those to get started. It can also be integrated into a site pretty easily, and you can see an example of that here. Click on the tab that says autotracker to take a look.

[skinsort]

Hey, here's a responsive application template I coded up a while ago. The different images show the different stages of it's appearance ranging from a mobile screen to a large one. You can use this in a post, or install it on your member info page on a jcink board pretty easily. You can see a version of this I implemented on my own board here.

[skinsort]

Toggle Script for Whatever You Need

I have a couple buttons members and guests can click in order to change their settings on my site, and I've posted a tutorial on how to implement one here. One on my site is for low graphics (basically turns animations and gifs off in most places) so that if someone is on their phone or an older computer or a slower network they can make their experience a little better. Another is for light/dark mode once I actually finish testing light mode. This tutorial is basically just some simple jquery and an explanation of how to use css properly to change any css based features on a site and store that information for your users. Like my other scripting stuff, it's probably best to use this if you already have a decent idea of how css and jquery work, but this one is simpler than the memberlist setup for sure. Hope this is helpful for people!

[skinsort]

Automatic Member Directory

I wrote a script to create an automatic member directory by scraping data from the jcink memberlist. A tutorial for it is here. And you can see how I've done it at my site here if you'd like to see a live preview. If it's aesthetically not to your taste or not compatible with your skin, worry not, the script etc is agnostic about how your site is coded and I don't actually provide any html/css structure. It's up to coders to adapt it for their own skin as they are all too variable for me to account for. As I say in the caution tutorial, this is definitely a piece of code for people who skin, and probably even people who have a decent understanding of javascript/jquery under their belts. It's not for beginners or a plug and play resource. But it is highly flexible and useful and once it's set up no one ever has to touch it again so! Tradeoffs lol.