« Ordering sticky topics
Improving how smileys are managed
Latest WIP: news feature »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Improving how smileys are managed
« on November 26th, 2012, 04:12 AM »
So, this was raised ages ago in the private area, and I want to bring it back for discussion. It is, after all, something of a mess.

First question: do we really need the facility for multiple smiley sets?

Second question: do we really need to ensure the same smileys are present in every set?

Third question, and this is one for the programmers rather than anyone else: can we safely ditch the predefined smileys shtick? Spoiler because it's long, messy and of little importance to most people, other than the UI aspect which I'll deal with afterwards.

(click to show/hide)
So, smileys have the predefined list hardcoded into the smiley code in a bunch of places, so that we don't have queries when we don't need them, except that anyone who uses customised smileys in any fashion - and that's probably most people who don't have a 'businessy' site - will be using customised smileys, and thus the performance aspect.

I seem to remember that it is cached, but that's not a hard thing to check and enforce. And even if we do have the whole multiple smiley sets (which I'm not entirely convinced needs to remain but I'm willing to go with the majority), it's not like we can't just cache everything and be done with it.

So there is a performance trade off for people who do use it, versus less hit for people who don't, but then we have the UI aspect...

I mentioned a UI problem. Adding a new smiley is incredibly unintuitive.[1]

So, if we don't have customised smileys, because internally it's *all* that customised gig, we get to massively streamline the UI. Depending on how the above other questions turn out.

Also: as far as I'm concerned you will have to use FTP/SFTP credentials to upload files. I really hope that's not a problem for anyone because I'm not prepared to budge on that; the whole point is to NOT have to change file permissions and thus encourage people to make things insecure by design.

Thoughts welcome.
 1. In fact, one of my side projects is a heavily modified SMF install (there's enough custom code that I don't want to have to keep patching to keep it level with Wedge, and I don't even see my keeping it beyond SMF 2.0). For reasons I won't get into, this project's smiley set was made out of a single sprite sheet, so I crudely replaced the code in SMF with that image and offsets and whatnot, and I showed the other folks involved on the project the UI, showing off the different smileys and all the codes attached to it - and the take-away comment was "I like the whole admin control. I wish SMF had such." - as in he thought I'd made the entire UI for customised smileys, solely because no-one had mentioned to him about enabling them.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

spoogs

  • Posts: 417
Re: Improving how smileys are managed
« Reply #1, on November 26th, 2012, 04:32 AM »
I've only ever used whatever the default smiley set is and never had the desire to change it nor has anyone ever asked about changing it. Not much i can really add I guess.
Stick a fork in it SMF

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Improving how smileys are managed
« Reply #2, on November 26th, 2012, 05:49 AM »
Seems to me the whole underlying code can be ditched and just store the smileys as a serialized array in the settings table, much like hooks.
A confident man keeps quiet.whereas a frightened man keeps talking, hiding his fear.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #3, on November 26th, 2012, 06:02 AM »
This is why I want to know how people use it, whether that will be enough.

Do people, for example, break out a festive set of smileys? Do sites generally have multiple sets on offer? Is it worth the complexity of code for it?

live627

  • Should five per cent appear too small / Be thankful I don't take it all / 'Cause I'm the taxman, yeah I'm the taxman
  • Posts: 1,670
Re: Improving how smileys are managed
« Reply #4, on November 26th, 2012, 08:14 AM »
I seem to recall a poll at sm.org asking which smiley sets they use there. The overwhelming majority left the default, then Aaron, then Akyhne, in that order. I think it was in 2010.

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Improving how smileys are managed
« Reply #5, on November 26th, 2012, 11:59 AM »
80% of the time I use default. The other 20% of the time I might have Custom smileys, I never have more then one set. I might replace default with a holiday themed set on sites but never have more then one set enabled/useable. I replace the images instead of adding another set because last thing I want to see out of a given holiday season is a smiley from Halloween or whatever during Christs Birthday or Zombie Day.
Thank you,
Boko

billy2

  • Trying to earn brownie points for a lads trip to the Red Sea. Minus 1 already - just for asking!!
  • Posts: 350
Re: Improving how smileys are managed
« Reply #6, on November 26th, 2012, 04:29 PM »
I think festive smilies are a nice touch.
Solosmilies are my default and change to a Xmas set next week.

Gives me something to do :hmm:
<br /><br />cough, cough.

garou

  • I really love the new system so far and can not wait to try it out for myself.
  • Posts: 17
Re: Improving how smileys are managed
« Reply #7, on December 20th, 2012, 03:33 AM »
While I do see a potential for seasonal smileys on some sites, generally it just seems most sites just add a ton of smileys for their users. Some sites have hundreds to be used and seasonal smileys are just listed as additional smileys rather then a specific set.

I also have the same issues with badges, while some sites like to have theme specific ones, most just use their standard badges set on every theme so as an admin having to copy the badges to every theme is a pain. Most SMF sites I worked on I usually just installed the mods for all badges in one directory and and the one for multiple badges.
Balance Games

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #8, on January 9th, 2013, 06:12 PM »
OK, time for crazy ass ideas.

The smileys are currently embedded into the main CSS file for the site, as data URLs. It strikes me that we can solve the problem of uploading smileys because of that.

What we could do is store the smileys' actual data in the database, push that to the stylesheet (rebuilding if necessary, don't really know how that would work), and that way we don't have to actually push FTP/SFTP information around and can safely handle everything that way.

What I'd be inclined to do is also set this stuff up when first installing, so everything's there, rather than having data in multiple places. It also means we can streamline this nonsense of 'enable customised smileys' and totally just rely on the DB to do it right the first time.

Thoughts?

godboko71

  • Fence accomplished!
  • Hello
  • Posts: 361
Re: Improving how smileys are managed
« Reply #10, on January 11th, 2013, 10:46 PM »
I'll throw in some ideas if I may..when you actually look upon smileys, what are they really? I mean, what do they represent? They are all shortcodes that means distinct things ("angry","sad", "lol"), the actual graphic representation can be very different, right? So why not only deal with the shortcodes, and let the graphic be up to the theme?

Whats needed then, is a easy way for admins to change themes, or part of them at least. A editor of sorts, one that can be as big as you like, would be able to jumble together different smileys to a "set", and save that as a sprite which is called from posts instead of single images, through CSS. You could make several sets, and set some criteria for when they are used, as easy as making a new BBC code [christmas][/christmas] where every emoticon inbetween those tags will use that reddish set instead of the normal yellow - or personal choice  on which set to use. One could even make users make their own..though i would not advise it lol.

There's drawbacks to this of course..but I feel there's more benefits than drawbacks here. Currently trying to make this actually work, but not quite there yet lol.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #11, on January 11th, 2013, 11:10 PM »
Theme is not the be-all and end-all of everything ;) :P I know plenty of sites that have many smiley packs and only one theme, and I know sites that have only one smiley set and multiple themes. Very often people do not want them tied together, they just want the ability to add them - to me this intimates keeping it away from the actual theme.

The pushing of it to CSS is mostly a convenience, but not for spriting purposes - but for inlining purposes. The smileys in Wedge are not served as files, not even as a single sprited file (which makes no sense for animated smileys anyway, for multiple reasons), but are inlined in the main compressed CSS file for the theme; all the theme files are combined, compressed and served as such, with things like the menu icons and other sprites being converted to data URLs and pushed into the CSS itself, which makes it even more efficient, because not only will the CSS be cached, so will the smileys without even generating an extra HTTP request.

What I'm getting at here is really a methodology of expanding the current system in a way that avoids security issues of folders, and expands upon what's there.

I can see where you're going, and in some cases it would probably be near enough optimal, especially if you wanted to do theme specific variations, but the problem is people do not necessarily want that, and would rather have specific sets of smileys or other images. I have one site, for example, where I have very specific images added as smileys, that wouldn't fit in any theme, wouldn't be in any theme, but they're used to convey a specific feeling, so I wouldn't want to ditch them.

It is an interesting idea, but it's not one that I particularly think we can viably explore in Wedge, though I'd love to hear how it turns out.
Re: Improving how smileys are managed
« Reply #12, on January 12th, 2013, 01:11 AM »
Yes, the drawback is that the theme will set the rules here..that you would have to copy over the smilies to more themes, to have the same all over. I am not entirely sure how I will solve that, but I see its one of the restrictions of the theme engine, that a theme does *everything* , often when theres no need since its already in default theme.The theme has the freedom to change *everything* - but not change *anything* and get the rest from default theme. The templates work fine in this respect - but not the rest. I have lost track on exactly Wedge does it lol, but building on each other seem to be the answer.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Improving how smileys are managed
« Reply #13, on January 12th, 2013, 01:18 AM »
Well, Wedge templates are fundamentally more modular than SMF ones, and there is a powerful (and complex) template nesting system, the advantage of which is that you can interject templates in between other templates.

But I never made any bones about the fact Wedge is more plugin rather than theme orientated, that's just the direction we wanted to take it. Given that, I was never comfortable giving the theme *too* much power, but it has *sufficient* power from our perspective for the most part.
Re: Improving how smileys are managed
« Reply #14, on January 16th, 2013, 05:24 PM »
Bump for Nao: what are your thoughts about storing the smileys in the DB and having them inserted in to the CSS from there? (I'm trying to avoid the need to push files to the file system unless necessary)
« Ordering sticky topics
Latest WIP: news feature »