Loomio

Restructure UI code.

JH Jonne Haß Public Seen by 91

I think we don't need to vote if we should do it, so this discussion is about how doing it. To make things easier we should keep the current design where possible for now and do design improvements when this is done. I'll list some possible requirements/alternatives to what we currently use/tasks:

HTML/Templates

  • Get rid of unused templates
  • Get rid of app/views/shared/ if still in use move them to better fitting places
  • Make clear rules on what to render on the server and what to render on the client side, get rid of handlebars and server side templates doing the same job.
  • Refactor the code to get rid of "styling HTML", like 99% of <br>s, potential <b> tags and whatever
  • Use semantically rich tags, like using <em> for something important, not because it looks cool.
  • Decide on either ERB or HAML, don't use both.
  • Use all the (semantic) power HTML5 provides.
  • Stop using casing as design element, that just localizes terribly as there are scripts which have no casing.

CSS

  • Make Layout responsive
  • Get rid of fixed sizes where possible (I'm looking at you, px)
  • Develop a clear and clean structure. Like for example one CSS file for each GET route + meaningful common usages Group the common usages by categories, i.e. forms.
  • Port every SASS code to SCSS, see #3796 [DONE]
  • Get rid of all :css/`` blocks in templates
  • Port everything from Blueprint to Bootstrap, see#4466

JS

  • Get rid of multiple libraries essentially doing the same where possible, i.e. the autocomplete ones.
  • Move everything to Backbone if possible.
  • Replace hacked libs with vanilla ones doing it right in the first place. If not found try to externalize the hack into another file. If not possible make it damn clear inside the library where the change it and why it was done with big fat comments, to ease the life of the updater.
  • Update all dependencies, replace them with gems if available (maybe even create some?)

While at the frontend code, the locale files too contain many unused keys and semi duplicates. A lot of the template code was moved around so I guess about the half of the keys is accessed using the full path, unable to take advantage of the dot syntax. Maybe we should develop a struture there that's independent from the template structure?

I'll keep this list updated with the ongoing discussion, so ensure you'll rescan it once in a while ;)

ST

Sean Tilley Tue 9 Oct 2012 4:03PM

Good thinking. While I think a new look and layout would be great in the future, we'd need to address what you've listed first.

Regarding being responsive: while I think it's definitely something we want, we ought to think about how we want to tackle it. The way I see it, we could first just make everything responsive on the grid first, and see how the following things might also be useful.

  • Responsive toolkit: I think Bootstrap does an okay job with this, but Zurb Foundation might be worth looking into, due to some of the interesting grid work their toolkit uses.

  • Actual responsive layout: simply scaling up and down a desktop layout can end up with an ugly design, but designing for mobile first and scaling it up to different form factors can actually be pretty efficient. Not to mention, it might not be bad to think about making a responsive clone of the existing mobile site and using one standard frontend.

  • Getting rid of Blueprint/unnecessary extra layout frameworks and relying on a simpler way to put the page together.

Just some thoughts. :)

ST

Sean Tilley Wed 14 Nov 2012 1:26AM

I kind of feel like this wouldn't be a bad thing to push for in 0.0.3.0 or 0.0.4.0. A lot of the CSS and template fixes shouldn't be too hard to do, and if someone would be willing to take care of the JS half of it, we could actually make quite an improvement!

FS

Florian Staudacher Wed 14 Nov 2012 10:07AM

I could dig into the JS part, but I won't have much time for that before mid-December or so...

DM

David McMullin Sun 18 Nov 2012 8:46PM

I'm happy to dig around any JS as well, I learned a fair bit about backbone while I was converting the tagFollowings (PR pending =) ) and my JS skills are way better than my Ruby skills anyway =)

ST

Sean Tilley Mon 19 Nov 2012 4:24AM

David, we could definitely use help on the JS end of things! :)

FS

Poll Created Fri 30 Nov 2012 10:29AM

Use .scss for all our stylesheets Closed Mon 10 Dec 2012 11:29PM

I think as web developers we can agree, that plain CSS is just not enough in some situations - no argument there - and since we have the Rails asset pipeline, Sass comes with it for free.
But until now we had a mixture of both the older 'sass' files and the newer 'scss' ones.

I propose we discontinue 'sass' and switch to 'scss' completely.

FYI, the project website has this to say, which pretty much contains all the arguments for and against either:

> Sass has two syntaxes. The most commonly used syntax is known as “SCSS” (for “Sassy CSS”), and is a superset of CSS3’s syntax. This means that every valid CSS3 stylesheet is valid SCSS as well. SCSS files use the extension .scss.
>
> The second, older syntax is known as the indented syntax (or just “.sass”). Inspired by Haml’s terseness, it’s intended for people who prefer conciseness over similarity to CSS. Instead of brackets and semicolons, it uses the indentation of lines to specify blocks. Files in the indented syntax use the extension .sass.

Results

Results Option % of points Voters
Agree 91.7% 11 ST FS TS JH F G T PP F DU DM
Abstain 8.3% 1 JR
Disagree 0.0% 0  
Block 0.0% 0  
Undecided 0% 43 MS AA S CB HF BO DM GC JH M EG G AX PP BB DY SH RF DM DS

12 of 55 people have voted (21%)

FS

Florian Staudacher
Agree
Fri 30 Nov 2012 10:33AM

familiarity with css makes it easy to write scss, so better for new devs. also, I personally don't like the haml syntax ;)

JR

Jason Robinson
Abstain
Fri 30 Nov 2012 11:59AM

Trust you guys on this :)

ST

Sean Tilley
Agree
Fri 30 Nov 2012 3:33PM

Let's do it. :)

PP

Petar Petrović
Agree
Fri 30 Nov 2012 4:51PM

I'm all for this.

G

goob
Agree
Fri 30 Nov 2012 11:21PM

Sounds like a good idea from what you say, although it means I won't be able to help with style sheets as I don't know SCSS (not that that will be much of a loss to you).

TS

Tom Scott
Agree
Fri 7 Dec 2012 5:04PM

I believe a run of sass-convert is all we need to convert our CSS to the SCSS syntax, however we will need to run some acceptance tests to figure out if the auto convert broke anything...

T

tortoise
Agree
Sun 9 Dec 2012 11:11PM

Making it easy for new/green devs is always good idea.

TS

Tom Scott Mon 10 Dec 2012 4:56PM

This is pretty much unanimously YES so let's make an issue. :)

https://github.com/diaspora/diaspora/issues/3796

I'd also like to put it out there to anyone on the contributors team to definitely review the pull request that will be made for this issue, as there might be/will be problems with CSS after an automatic conversion such as this.

F

Flaburgan Mon 24 Jun 2013 8:22AM

Decide on either ERB or HAML, don't use both.

I'm absolutely not in the Ruby world so I don't know if HAML is the most used language, but I don't like it at all and I think that, like me, many persons know HTML but not HAML. Keep a HTML syntax could unlock the number of contribution in the front end part. We can say the same about sass which is not better than scss (as far as I know) but does not allow people who simply know css to participate.

So I'm for scss (this was already voted) but also ERB, what do you guys think?

The issue for scss is on github, the work was partially done, maybe we could ask with DiasporaHQ if someone wants to continue working on it?

F

Flaburgan Thu 4 Jul 2013 8:53AM

I'd be happy to work on the refactor of the UI part, but I don't love the HAML syntax. I know, tastes are different, but I really think that a lot of people are like me: they know HTML and would love to make some quick fix, but when they see that the views are written with a language they don't know, they just give up. For me, it's a blocking point for newcomers. What do you think?

ST

Sean Tilley Mon 8 Jul 2013 5:15PM

I wouldn't mind getting rid of the HAML and just using good old-fashioned erb, honestly.

JH

Jonne Haß Mon 8 Jul 2013 6:25PM

Before we consider that we should first clean up all unused HAML templates. There should be quite a lot of these by now.

F

Flaburgan Tue 9 Jul 2013 8:20AM

I am working on refactoring the frontend stuff. I started with the left bar side menu, because the fixed widths break design in french. I think I'll finish having a nice plain HTML code today. Should I convert it to ERB or HAML after that?

(please, please say ERB :p)

R

Ryuno-Ki Fri 21 Feb 2014 10:57PM

Thank you, @seantilleycommunit, for allowing me writing here :-)

@flaburgan Don't confuse HAML with YAML ;-)

I've worked for a small company using RoR. They were moving from HAML to Slim and I took the chance to learn HAML :-)

I'd say, I'm pretty familar with it, although there are certain circumstances, where it becomes pretty difficult to write clean HAML markup …

I was going to review the view files soonly anyway :-)

R

Ryuno-Ki Tue 25 Feb 2014 9:57PM

Hm, that's challenging.

I'm converting the .erb (but not .markerb) files into .haml using html2haml (works with .erb, too!).

However, it's not that easy (read: currently impossible) to mix JavaScript and Ruby interpolation at the moment.

For the record: For compiling .js out of .haml, wrap the code inside a :javascript filter (search the docs), which leads to the appropriate script-tags.

It's recommend to move the JavaScript code out of the markup. Shall I open a ticket for it?

F

Flaburgan Thu 27 Feb 2014 8:12AM

Hi, most of the front end code is dirty, we clearly need a real refactor, not only a conversion. This is currently done during the port to bootstrap.

R

Ryuno-Ki Fri 28 Feb 2014 12:42AM

With whom I would need to get in touch? I could coordinate the contribution then.

Found a list by @seantilleycommunit which may add some value to the description above.

F

Flaburgan Sat 1 Mar 2014 10:22AM

@ryunoki I am the one who does most of the port from Sass to Scss (see #3796) and manage css files. @steffenvanbergerem is the one who does most of the port from blueprint to bootstrap (see #4466)

Simply warn on these issues when you want to do something, and do it :) Don't hesitate to ping us on github or IRC if you need help.

R

Ryuno-Ki Thu 13 Mar 2014 7:00AM

Hm, will simply comment on it in the hope of getting informed on further comments … this week, I'm working on finishing my own projects ;-)

G

goob Wed 2 Apr 2014 10:20PM

Should we take a vote on whether to use ERB or HAML, or is more discussion needed on that issue first?

ST

Sean Tilley Thu 3 Apr 2014 10:53PM

Might as well just vote on it.