Project

General

Profile

Feature #9313

Feature #8580: Installation Assistant

Feature #9310: Assistant: Implement a first web prototype of the assistant

Assistant: Format router using Bootstrap

Added by sajolida about 4 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Category:
Installation
Target version:
Start date:
Due date:
% Done:

20%

Feature Branch:
web/9313-format-router-using-bootstrap
Type of work:
Website
Blueprint:
Starter:
Affected tool:
Installation Assistant

Related issues

Blocked by Tails - Feature #9312: Assistant: Dump content of router in ikiwiki pages Resolved 05/01/2015

History

#1 Updated by sajolida about 4 years ago

  • Blocked by Feature #9312: Assistant: Dump content of router in ikiwiki pages added

#2 Updated by sajolida about 4 years ago

  • Affected tool set to Installation Assistant

#3 Updated by tchou about 4 years ago

  • Assignee changed from tchou to sajolida

First work on bootstrap implemation on windows path :
- add router.css
- add some html bootstrap markup

http://repo.or.cz/w/tails/tchou.git/commit/95de7c9383f149c53eb8d69336cb6f6be37d5651

#4 Updated by tchou about 4 years ago

Some extra improvements on this repo :
- generalize and unify panel markup
- back button style

#5 Updated by sajolida about 4 years ago

  • Assignee changed from sajolida to tchou
  • QA Check set to Dev Needed

I tried to fetch from your report but I think that it still has all the old Git history that DrWhax and intrigeri clearned in February.

remote: Counting objects: 180989, done.
remote: Compressing objects: 100% (56930/56930), done.
Receiving objects:   3% (5481/180989), 1.03 MiB | 34 KiB/s      

It seems like I have to download many many megabits of stuff which looks weird.

Did you do that back in February: https://mailman.boum.org/pipermail/tails-dev/2015-February/008264.html.

Also, I see from the diff on repo.or.cz that it includes unrelated binary files:

  • UX-and-security-fast-overview-on-extention-and-installer-improvements.odg
  • booting.mdwn~
  • compare-proposals.ods

Please also don't commit unrelated changes to PO files.

#6 Updated by tchou about 4 years ago

#7 Updated by tchou about 4 years ago

  • Assignee changed from tchou to sajolida

#8 Updated by tchou about 4 years ago

  • QA Check changed from Dev Needed to Ready for QA

#9 Updated by intrigeri about 4 years ago

  • Status changed from Confirmed to In Progress

#10 Updated by sajolida about 4 years ago

First of all, it's really cool to be able to see all our work on web
pages, yeepee! I also find that Bootstrap looks both great and easy to
read. Now that your code changes most of those pages, I will refrain
from modifying the content, for example from tasks #9559 and #9441
until I can merge your changes or otherwise we will have to deal with
many deep conflicts.

Here are some comments, some of them are more serious than others. I'm
also conscious that I am a bit maniac and we should work on finding a
level of expectations that is both acceptable for the project and
comfortable for you. Don't hesitate to tell me when you think I'm
exagerating.

I think we have two options to continue working on this:

1. You do incremental improvements on your code to fix those issues as
commits add to your branch.
2. You rewrite your commits and change the history of your branch.

Ideally I would like to improve on the Git history (read on about
that) and on the total diff (git diff
origin/web/assistant...web/assistant
).

About code style:

I think that having consistent and beautiful code is useful to make it
easier to read, easier to modify and maintain, and easier for
translators to translate. To the light of this, here are a few
comments:

  • Avoid trailing white spaces. You can spot them in your commits by
    activating colors, see 9130#note-12. Then you can do git diff
    origin/web/assistant...
  • Please do smaller commits. A commit should correspond to one idea or
    one problem. It should be possible to revert or analyse commits
    separately. Big commits make it harder to understand you work as
    several things get mixed up. At least separate changes on the
    content from changes in the format. For example, your commits
    commit:3423fc9 and commit:37bd3d8 are good. But your commit
    commit:4f99f0f mixes way to many changes. It might be hard (but not
    impossible) to rewrite the history of your commits to make them
    smaller. You can start by doing git reset d301037.
  • Also try to limit your impact on the existing code to have smaller
    diffs. I'm not sure that's possible in your case but that's an idea
    to keep in mind: if you can leave a line unchanged, try to do it.
  • Please use indentation consistenly. So far we've been using ' ' to
    indent HTML. You're mixing ' ' with tab. I prefer ' ' and sometimes
    don't indent in order HTML indentation, you're mixing both 'tab' and
    ' ' inconsistently, let's do the same thing everywhere.
  • Avoid empty lines. For example in
    wiki/src/install/debian.mdwn. Making your code more compact (but not
    too much) makes it faster and easier to read.
  • Add empty lines between separate blocks of text (or code). Otherwise
    translators will see them as a single string. For example on
    install.mdwn there should be an empty line between <h1>Welcome to
    the Tails Installation Assistant</h1>
    and Thank you for your
    interest in Tails.
    .
  • Use full HTML and always add <p> for example inside a <div>. For
    example in <div class="panel-body">If you know someone of trust who
    uses Tail
    . Otherwise this might break your formatting or produce
    unexpected results as the HTML wouldn't validate.
  • Avoid unecessary spaces. For example in <li> 25 minutes to
    install
    . I'm not a browser compatibility expert but I could see
    this creating problems in some unexpected corner cases.
  • Why not use consistent color codes? So far we've been using the
    format #rrggbb consistently. You started using rgb(40,40,40) and
    green. I could see this creating problems if we want to use grep
    or replace one color by another everywhere consistently in the
    future.

About the code itself:

About the formatting:

  • We haven't used SVG images so far. I think that boum.org doesn't
    have whatever imagemagick dependency required to use them. We could
    probably ask them to add this. I'm also wondering whether this can
    cause display issues on older browsers or security issues (it is
    possible to add executable code to SVG images). Do you think we
    could use PNG instead? If so please also use the script I added with
    4a1bf7d to compress them.
  • Why did you choose to switch to a blue theme (or maybe that's
    temporary only). What about reusing our usual color sheme with
    purple and green?
  • I find the grey on the minor (DVD + VM) way to pale and can hardly
    read it. I'd rather format them more explicitely as links using our
    usual colors.

That's quite a lot of comments already, so I'll stop here. Good luck
with Git and don't hesitate to ask for help on using it.

#11 Updated by sajolida about 4 years ago

  • Assignee changed from sajolida to tchou
  • Target version changed from Tails_1.4.1 to Tails_1.5
  • QA Check changed from Ready for QA to Dev Needed

#12 Updated by tchou almost 4 years ago

  • Target version changed from Tails_1.5 to Tails_1.6

#13 Updated by sajolida almost 4 years ago

  • Priority changed from Normal to Elevated

This has been post-postponed twice already, so raising priority.

#14 Updated by BitingBird almost 4 years ago

  • % Done changed from 0 to 20

#15 Updated by tchou almost 4 years ago

  • Target version changed from Tails_1.6 to Tails_1.7

#16 Updated by tchou over 3 years ago

  • Assignee changed from tchou to sajolida
  • QA Check changed from Dev Needed to Ready for QA
  • Feature Branch set to web/9313-format-router-using-bootstrap

1. You do incremental improvements on your code to fix those issues as
commits add to your branch.
2. You rewrite your commits and change the history of your branch.

I started back from sratch. I merged my local bootstrap branch on my local web/assistant and branched it to make this one. Otherwise I would have had to copy its content anyway.

I tried to do small commits, you will see that sometimes there are missing files (I use to do git add . and doing git add myfile, I miss files sometimes).

About code style:

I think that having consistent and beautiful code is useful to make it
easier to read, easier to modify and maintain, and easier for
translators to translate. To the light of this, here are a few
comments:

  • Avoid trailing white spaces. You can spot them in your commits by
    activating colors, see 9130#note-12. Then you can do git diff
    origin/web/assistant...

I think my text editor is suppose to kick it now before saving, but I should check again. I don't always go git diff before commiting.

  • Please use indentation consistenly. So far we've been using ' ' to
    indent HTML. You're mixing ' ' with tab. I prefer ' ' and sometimes
    don't indent in order HTML indentation, you're mixing both 'tab' and
    ' ' inconsistently, let's do the same thing everywhere.

I tried to use single spaces, but it's very difficult for me to read the code after so I did it with tabs.

  • Avoid empty lines. For example in
    wiki/src/install/debian.mdwn. Making your code more compact (but not
    too much) makes it faster and easier to read.
  • Add empty lines between separate blocks of text (or code). Otherwise
    translators will see them as a single string. For example on
    install.mdwn there should be an empty line between <h1>Welcome to
    the Tails Installation Assistant</h1>
    and Thank you for your
    interest in Tails.
    .

I did it in this example and had a quick look to the rest, but maybe there is some other cases.

  • Use full HTML and always add <p> for example inside a <div>. For
    example in <div class="panel-body">If you know someone of trust who
    uses Tail
    . Otherwise this might break your formatting or produce
    unexpected results as the HTML wouldn't validate.

I had this in mind coding, but maybe I missed some. Some of the bootstrap exemple I used do not contain p : http://getbootstrap.com/components/#panels

  • Avoid unecessary spaces. For example in <li> 25 minutes to
    install
    . I'm not a browser compatibility expert but I could see
    this creating problems in some unexpected corner cases.

I don't know what could happend, but I tried to remove them.

  • Why not use consistent color codes? So far we've been using the
    format #rrggbb consistently. You started using rgb(40,40,40) and
    green. I could see this creating problems if we want to use grep
    or replace one color by another everywhere consistently in the
    future.

I like rgb because it's easy to read it and to move by hand from black to white, but I changed it.

About the code itself:

Ok.

You can rewiew it in any dimensions you want : html, css, graphic layout... For me it's in a good shape (except that I did it today so maybe tomorow I'll change my mind :)

#17 Updated by intrigeri over 3 years ago

I think my text editor is suppose to kick it now before saving, but I should check again. I don't always go git diff before commiting.

Hint: git diff --cached (after git add -p and/or git add $FILE) shows you what you are going to put in the commit you're preparing, that is what will be recorded next time you run git commit.

I tried to use single spaces, but it's very difficult for me to read the code after so I did it with tabs.

Could N-spaces (N = 2 like in Ruby, or a larger N like in most other programming languages) be a compromise that works for everyone?

(All Tails stuff is standardized on "no tabs", and FYI introducing tabs in this context makes collaborative work painful. It's not just a matter of "everything must be the same because of my OCD", I can elaborate privately if you wish :)

#18 Updated by tchou over 3 years ago

intrigeri wrote:

I think my text editor is suppose to kick it now before saving, but I should check again. I don't always go git diff before commiting.

Hint: git diff --cached (after git add -p and/or git add $FILE) shows you what you are going to put in the commit you're preparing, that is what will be recorded next time you run git commit.

I know this one (as "--staged" too).

I tried to use single spaces, but it's very difficult for me to read the code after so I did it with tabs.

Could N-spaces (N = 2 like in Ruby, or a larger N like in most other programming languages) be a compromise that works for everyone?

Actually, I think it's what I do, but I can ask my editor to normalise the codebase.

#19 Updated by sajolida over 3 years ago

  • Priority changed from Elevated to High
  • Target version changed from Tails_1.7 to Tails_1.8

Postponing and raising priority.

#20 Updated by sajolida over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (sajolida)
  • QA Check deleted (Ready for QA)

Merged!!!

Also available in: Atom PDF