Page template & CSS rewrite

[virtualtam]

Goals

• provide W3C-compliant HTML5 & CSS code
• improve metadata, add semantics (see Add OpenGraph metadata #258)
• rewrite page templates using a modern, lightweight engine
• hook template rendering with an HTTP router (see Use a PHP micro-framework #655)
• rewrite the main stylesheet: simple, responsive and flexible (easy to extend/override)
• use an icon font subset instead of images
• give the community fork its own identity (see About the "branding" of this fork opposite legacy Shaarli #203)

Available libraries

Template engines

• RainTPL, RainTPL3 the official website is down -domain suspended, and the repositories don't seem actively maintained...
• Dwoo no built-in integration in Slim/Silex
• Smarty
• Twig

Responsive stylesheets

• Bootstrap, and Bootswatch for custom theme design
• Ink
• Smart Grid

Icon fonts

• Font Awesome
• Glyphicons
• Ionicons
• Glyphsearch (font search engine)

Resources

• Dive into HTML5
• HTML Dog
• Responsive design guidelines
• CSS tricks

Notes

• this started as a discussion brought by @nodiscc on Gitter
• everyone is welcome to provide feedback or suggest other frameworks, libraries and resources, I'll keep this issue updated :)

[ArthurHoaro]

Hijacking my comment to reference changes made or to make on Shaarli's core to handle new templates.

Translation

See #627

I've added a wrapper function called t() to handle future translation. Every translatable string need to be called this way in templates:

<p>{'translatble'|t}</p>

or for plural forms

<p>{function="t('%s comment', '%s comments', $nbOfComments)"}</p>

Tokens

See #625

I've added a login form in the header, which requires a token everywhere. A token variable is now passed to every template.

Timezone

TODO - EDIT: this is planned in #372

The timezone selects need to be updated to be displayed properly on mobile.

Plugin placeholders

See #679

A few plugin placeholders (e.g. in the header) don't work properly with other templates. They need to be reviewed.

URL management

TODO - Related to #292

Adding a function to generate URLs would ease later URL maintenance, and will allow to handle an optional URL rewriting properly in the future.

---

Original comment:

That's very clear. :)

My two cents:

• maybe we can work a current template designer or base this rewrite on an existing template.
• I've worked with Twig (Symfony), it's a great engine with a lot of features and a large community.
• Bootstrap might be overkill, and I believe it relies on jQuery. Ink seems also large. Smart Grid seems to only handle a grid system. Maybe we could try to find something in the middle.

[kalvn]

I discovered recently another CSS framework which seems way lighter than Bootstrap : Pure.css. It weighs 4 Ko.

I didn't tested it by myself but I had a look at the documentation and it seems quite nice and straightforward.

[ArthurHoaro]

From what I see, solid basic features, light, no JS. Also, it looks mature, and it's maintained by Yahoo! organization and has 13k+ stars on Github.

That seems great!

[dper]

No JS, great! 👍

[nicolasdanelon]

Hi I saw this framework, seems to be good and solid, lightweight and has a little baseline for a quick start.
I also like puse.css , never use it before but look awesome

[ArthurHoaro]

skel looks more like a JS frontend framework, with a SASS based CSS. I'm not sure we need those.

[nicolasdanelon]

all right.. no prob !

[mlanner]

Depending on how this feature is implemented, it would probably be nice with a "standard" place for templates to live. In my current setup I put templates into tpl/TemplateName-version and symlink templatename to tpl/TemplateName-version for simpler updating and version tracking of themes.

In trying to update Shaarli itself, I've discovered that my convention might not be the best, as the Shaarli .gitignore file doesn't ignore anything in tpl. Therefore, I think a better theme solution would be to have a dir tpl/themes and then stick the themes in there.

I guess for now, although it seems a bit wrong, I'd actually be better off putting my themes into data/themes and symlink back to there. At least for the time being, that would not (potentially) delete my themes when I upgrade Shaarli.

[ArthurHoaro]

My first contribution here #74 was actually to move the default template to tpl/default. It wasn't merged at the time because custom themes weren't a priority at all. But we should do this, and then add to gitignore:

tpl/
!tpl/default/

For now, you can move your template in the data folder as you suggested, or use your global git ignore file.

[alexisju]

In same time, git pull in the root of your Shaarli (to update it) wont overwrite your specific template located into tpl/ (neither your data/config.php - the file where you can set the path of your template). Or maybe i don't understand well the issue...

[nodiscc]

Work started in branch webdesign, as per #308 (comment)

[mro]

#308 (comment): any idea is welcome …

I recently turned away from server-side generated HTML markup, if there's already XML data. Examples are http://rec.mro.name/stations/m945/2014/06/07/2000%20Breakbeat-Action or https://drop.mro.name/galleries/demo/

So the server-side PHP template engine could be removed entirely. Javascript makes date+time human readable but isn't required otherwise (see the first example on top).

I understand that this is quite radical and off mainstream, doesn't work so well for non-content pages (admin stuff) and uses the totally non-hip XSLT, but it's IMO definitively minimalistic to the extreme.

Isn't dropping all server-side templating appealing? What do you think about it?

[nodiscc]

For me this feature

works with Javascript disabled

is a major selling point of Shaarli. I still have JS enabled but like the fact that Shaarli doesn't depend on it. I prefer the server to do the heavy lifting (as opposed to client side parsing/rendering.

[ArthurHoaro]

@mro That's an interesting concept to serve XML data as simply as possible. Although I don't really see how it's relevant here? Since Shaarli doesn't use XML data and is more complicated than just storage, we would have to render XML instead of (x)HTML.

On a side note, I'm spending half my work day doing XSLT these days, and it makes me want to drown kittens. :)

@nodiscc I agree.

[mro]

Javascript … Shaarli doesn't depend on it

I totally agree and invite you to view my two examples #266 (comment) with JS disabled, too.

Since Shaarli doesn't use XML data

it does: http://shaarlidemo.tuxfamily.org/Shaarli/?do=atom

I'm spending half my work day doing XLST these days, and it makes me want to drown kittens.

well, then you could the other half of your day…(duck)

[nodiscc]

Need to consider #517 (comment)

note that it might be a good idea to make each button easily hideable via CSS when rewriting the template (#266) (eg. <div id=rssbutton> in template, let users add #rssbutton { display: none } to custom CSS)

[ArthurHoaro]

Comment updated

[ArthurHoaro]

Hi guys! I've something more or less working on the webdesign branch. If you could give me some feedback, that would be nice.

http://workspace.hoa.ro/shaarli/

• login: demo
• password: demo

The config file is on read-only.

Also, the commit log in the branch is a total mess, I might have to just rebuild it from the start.

[alexisju]

Nice :-) However for a defaut template, i would prefer something more "neutral" (about design, colors, etc), more like Framasoft do with my.frama fork (https://my.framasoft.org/).

[mro]

While the core functionality (add a link) still works – thanks a lot – the 'delete' breaks: https://travis-ci.org/mro/Shaarli-API-test/jobs/173519278#L221

I'll have a closer look, if there's a chance to get that backward compatible. @ArthurHoaro what do you mean?
I guess https://github.com/mro/Shaarli-API-test/blob/master/tests/test-delete-all-ok.sh.xslt#L33 doesn't find the entries.

[ArthurHoaro]

@alexisju Myframa uses Material design, which I try not to reproduce here. I think I can get a bit more vanilla result by removing the green bar with the title.

@mro That's because I cherry-pick'd #682 which breaks backward compatibility. I'll push its milestone and see what I can do. What do I mean about what?

[mro]

What do I mean about what?

@ArthurHoaro about the delete compatibility. Frankly I'm not too keen about it, I don't use it and as long as nobody else complains, I'm be fine with GET requests.

But what puzzles me, is that when installing and testing it, the test fails in an a bit odd way.

Maybe I drop the delete test.

[mro]

I finally found it: it's the lf_linkdate form field doesn't exist no more. Could you add it back in?

[ArthurHoaro]

Hi! I've removed the big green header to get a bit more neutral result. Let me know if you have any suggestion.

[aurelg]

I just checked the demo instance, which I find very nice, and much, much better than the current theme. The overall layout is much cleaner. However, the green color might not suit all tastes. Is there a way to change it without modifying the CSS itself? It would be awesome to be able to define it with a parameter somewhere. If it's hardcoded, then maybe a black/white/grey theme would be safer (think wallabag)?

[elpiolito]

Hi. I've just discovered the new theme, good idea, it need a cleanup :)

Just checked the demo instance, here a list of problems I found (some of them are question of taste) :

• as aurelg, i find the green color awful. For me, it looks like an old UI (which is not the purpose of this design). The noise texture looks old too, maybe not putting it on each components.
• The green shadow under each title's card is not beautiful too. It seems there is a border bottom under each title div, not really beautiful.
• Contrast between title's card font color and title's card background color is not enough marked. It's difficult to read and is not accessible. (for checking : http://webaim.org/resources/contrastchecker/ , foreground #d0fff0 et background #20b988). Same problem with top toolbar and share link form.
• On firefox/linux, font weight not clean, seems a little bit blurred on title's card (same on tag on each card). No problem on my android phone.
• Qrcode, permaling, webarchive button too small. Not really a problem on computer but it's more difficult to touch the good one on smartphone.
• Login/Logout button must be after rss feed instead of before (see list on smartphone)
• Card margin left and right too big on smartphone, you could enlarge card when width reduced. In my opinion, left margin could be around 3% when width=360px (and card size around 94%)
• Bug : when i click on search button when i'm in the middle of the page, didn't show searchbar under top toolbar, i need to scroll up to see it. Really disturbing.
• On daily shaarli, margin too small, articles seems stuck together.

What i like :

• Responsive :)
• Icons (good choice for font awesome)
• Hide/Show button
• Content card rendering seems clean (maybe remove the noise on background for full white).

good luck

[ArthurHoaro]

@aurelg I don't plan it, but the CSS can still be overridden using user.css

On firefox/linux, font weight not clean, seems a little bit blurred on title's card (same on tag on each card).

@elpiolito Hmm... Maybe it is. Can you add a screenshot to see if we see the same thing?

---

So I got a lot of useful feedback by asking publicly (see the demo - warning: French), there is still quite a bunch of things to do, but I can see a PR happening by the end of the month.

[kalvn]

This new theme is by far nicer than the original one. It's way more modern and way less "geeky" which will help to seduce more users.

Actually, before listing some remarks about it, I'd just like to share a feeling. Even though the work put into it is really impressive, I can't help myself seeing the ghost of the original theme. The structure looks in fact quite similar (almost same top menu, same search with two fields, same filters arranged the same way, same footer, etc.). Wouldn't it have been worth rethinking the whole thing from the beginning? I'm sure the Shaarli community contains people used to deal with User Interfaces and User Experience in general. In the same way developers contribute to the core of the tool, that would be awesome to have some creative people proposing new ideas to improve the usability. I say this especially because I really suck at being creative but I often see wonderful ideas over the internet in terms of webdesign.
Of course, such work would require to first put ideas on a piece of paper, before starting coding. A good design is absolutely not easy to create but it can be an interesting journey.

Anyhow, I really like this new design and really do not want to look preachy. All this work was absolutely necessary and was greatly done. I just try to start thinking of the future of this amazing tool's appearance.

A few points in disorder:

• That would be nice to increase the padding on the top menu, at least when the scroll position is at the top of the page, to improve usability on mobile.
• The controls between the top menu and the main content of the page looks a bit too stacked. Wouldn't there be a way to organize them differently, especially for large screens? Maybe putting the numbers of links to the left at the same level than pagination.
• The green doesn't shock me at all. I agree that not every one likes green but this one doesn't look agressive to me. It's actually well balanced and gives an identity.
• I'm not a big fan of the noisy background. A very light and flat gray may be better for readability.
• The menu doesn't work for me when I reduce the width of the browser. The hamburger menu animates but nothing else shows up. I'm using Chrome right now.
• The content is quite dense at first glance. Since the most important information is links' title and description, wouldn't it be nice to enhance their visibility to the detriment of the rest (even hiding - one-click away - information that most people rarely need)? More space between lines and between links may help.
• That would be great to add hover and active styles to a maximum of controls to improve their usability and accessibility.
• The Tools menu looks really great!
• In the plugin admin, the button to move plugins up work, but the bottom button doesn't.
• In the daily, the links overflow from their container. Using truncation with ellipsis could be an idea.

[nodiscc]

I really like the new template so far. @ArthurHoaro I believe you addressed most of the criticism found in comments, well done. A few remarks, mostly about grouping items:

• Edit/delete/ buttons should be grouped together, in the same place (probably on top-right hand of the container, or maybe top/left?)
• Private status indicator should be displayed on the top left hand of the container, along with other status indicators (notes vs links)

About the color scheme, people with different tastes will inevitably want to change it (though I like the default one) so it would be good to provide a way to change major theme colors/provide a custom CSS.

enhance their visibility to the detriment of the rest (even hiding - one-click away - information that most people rarely need)?

A button to collapse all shaares (collapsing is a nice feature btw) near the items per page setting should do the trick

[ArthurHoaro]

@kalvn Well, I've rewritten the templates, but it's still Shaarli. Also I though it would be nice to have UI consistency between the templates. In any case, all kind of UI improvements can still happen in the future if we get good propositions, but it would probably require core changes, which are out of the scope of this issue.

Since the most important information is links' title and description, wouldn't it be nice to enhance their visibility to the detriment of the rest

I think that this issue is covered by the grey/blank background contrast.

@nodiscc

Edit/delete/ buttons should be grouped together, in the same place

It was at first, but I actually got the opposite feedback, to avoid unfortunate miss-click, especially on mobile where the buttons aren't that big. And I kind of like how it is with the delete at the bottom. Still changeable though.

Private status indicator should be displayed on the top left hand of the container

It was also, but it broke titles alignment, and the important information is the title. The orange bar now makes it immediately visible that the link is private.

About the color scheme, people with different tastes will inevitably want to change it (though I like the default one) so it would be good to provide a way to change major theme colors/provide a custom CSS.

It's possible, but it would hackish (override the CSS 'on the fly'). I'd rather do that in a plugin.

---

About the green, I kinda like it, but it was more a random choice in a flat UI colour picker. Although, I wanted a dominant colour to give the theme its identity, and green because the current template uses green also. Unfortunately, the current green doesn't do well as a background. Anyway, the green isn't too present now, but if someone has a better result with another green, I'll look into it.

I think I've covered most of the feedbacks I got. I have to add the latest merged changes, run a W3C check, recreate a clean branch and I'll submit a PR.