Make "Themes" more robust and customizable

[bnvk]

This issue may or may not be of interest and desirable to the Shout community as well as to @erming whom I know is in the middle of a big re-write of Shout, but I wanted to bring this idea up.

It seems to me the current implementation of "themes" in Shout really only allows for very light styling and CSS, not more robust themeing like one is able to do with WordPress or other platforms.

Personally, I have multiple real world use cases which would make immediate use of a more robust theming system. These cases orbit around making the user experience of using IRC orders of magnitude more simple. Among these are features are things like:

• Having a user automatically signed into one or multiple "fixed" servers + channels and unable to leave these channels
• Hiding the idea of "Server" altogether from the UI
• Hiding the idea of "channels" all together from the UI
• Significantly restructuring the layout of the message view
• Adding in a shim "avatar" style icon for each user
• Differing layouts of the interface (moving users bar to left / hiding channels all together)

All of these cases strive to push IRC interfaces more towards something like "Slack" which is quite desirable and used by many these days, which is unfortunate that it is not built on top of an open & public protocol like IRC. Thus, my interest in Shout and making IRC more awesome to use 😁

I would love to help work on Shout and contribute this sort of more advanced "themeability" as opposed to just a fork of this project which feels counter productive and less awesome. Hopefully there is interest from Mattias and the community as well!

See #380 and #384 for more context

[simonv3]

I'd definitely interested in these kind of things. It looks like there's some plugin functionality already suggested in an other PR (#320). I wonder how extendible that is?

[jancborchardt]

Most of these things could also be built into Shout itself rather than just be a theme. That would also ensure we spend our little time working towards a common goal. That would be the last 3 items in your list.

And the first 3 points of hiding functionality could go into a config switch to restrict functionality for specific cases. Basically the same thing you talked to @aspic about in #380

TL;DR: At this point of Shout development it seems that building a »Theming« system which goes beyond the easy ability to change the main color and a logo or so is time that would be better put into improving Shout in general. :) (So basically I fully agree with the points, I just think they should be in Shout itself.)

[easymac]

I am of the opinion that good usability avoids storing things in configuration that cannot be changed within the app - which, if the configuration hides things such as the settings menu, isn't possible without user roles. This is to say that I agree with user restrictions belonging in configurations, not themes, but hope that the final iteration of these settings allows them to be configured without SSH/file access.

Regarding theming: While I think that these suggested modifications are better suited towards configuration than themes, I like and fully support the notion of themes including not only CSS but also the relevant template files. The current CSS-theming system is fantastic: limitless customization in a "universal" web standard. I've never known software that could be customized by users to the degree that CSS customization allows. I see being able to modify theme templates the same way- radically increasing customization possibilities without increasing customization difficulty.

That's just my two cents on the direction theming should go (in the long-term).

I have been working for a couple months on a web app written in Meteor to host at shout-themes.com. Its purpose is to host theme files. There is still some work needing to be done but I am hoping to take it live within the next month. Regardless of how themes end up, I intend to stay up-to-date and support the Shout community in that way. If there are any ideas that you guys have for themes that might rely on an external theme database, I'll have one of those and can (hopefully) help with that.

The site will be open source when it launches.

Sorry for all the text.

[bnvk]

@easymac re: "user restrictions belonging in configurations, not themes" I agree with that sentiment which is how I initially started out as I was following @aspic lead.

However, i'm also considering if a person setting up Shout is only hiding something from the UI to make Shout + IRC more user friendly, there might not be a reason to actually disable users joining or leaving channels & networks. So, maybe the right answer is something like:

• Allow Shout owner to have default channels & networks that CANNOT be unjoined (specify in config)
• Allow Shout owner to globally disable joining / leaving channels & networks
• In the UI hide the buttons that correspond to config settings

Thanks for the thoughts and for building something that sounds like it will be useful 👍

[erming]

Let me quickly explain the Shout architecture before I dig into how we could improve themes.

Simply: it's made out of two parts. A server and a client.

Server:

• Socket.IO server
• Web server (serves the client/ folder with express)
• Handles the IRC connections
• Handles users

Client

• Uses a WebSocket to talk to the server
• JavaScript (jQuery, Handlebars and Socket.IO)
• HTML/CSS

Whenever the server receives a message from any of the IRC networks, it will parse the message and then relay it as JSON to the client(s).

The client is mostly a "thin client" in the sense that it doesn't do any updates to the UI without the server telling it to do so. All it really does is listen to events sent by the server.

But what are themes? How could we improve them?

Today, themes are just simple CSS files. While that's great for changing the looks, it doesn't really cut it if we want to move things around or change the interface behaviour.

But if I were to improve themes to be something more than just CSS, the distinction between server and client is important to know about. Altering server behaviour via themes would be alot harder and error-prone. It is possible, yes, but I just don't think it's a good idea.

You guys are already on the right track here. Some things should be built into Shout rather than themes.

So here's my idea:

Themes would be client-side only. Meaning that a theme would consist of its own templates, CSS and javascript. Here's an example folder structure, just to show you what I mean:

themes/
  foo/
    templates/
      channel.tpl
      msg.tpl
    foo.js
    style.css

Building the client like this would make Shout alot more customizable.

And taking these ideas one step further: themes could be npm packages. Then I could implement something like this: shout install-theme foo, which would then use npm to download the themes into the right folder.

Ping @bnvk, @jancborchardt, @easymac

Thanks for a healthy discussion, guys. I'm only sorry that I've not replied to you earlier. I've just had so many other things going on for a while, but it's finally settling down now.

[bnvk]

@erming cool. Thanks for elaborating on this, it definitely gives me a slightly better insight into how to proceed with some of the goals I mentioned. Glad things are settling down a bit ;)

[bnvk]

@erming I've been making a bit of progress on this. It'd be great if you could checkout the diffs so that I'm heading in the right way and not making in gaping mistakes 😉

Here is the diff of the changes I'm proposing to Shout

master...bnvk:master

And here is my working theme "Slick" that can be installed into the themes/ directory

https://github.com/opensourcedesign/slick