First steps toward a responsively designed client #42
Conversation
Does this mean I should be editing `CNeditor.css` instead of the .styl files here?
[Matthew Butterick](http://practicaltypography.com/point-size.html), author of Practical Typography, observes that a lot of people make the body text too large in their print documents, but too small on the web. A comfortable font size on the web is a little bigger than a comfortable font size in print.
It's much, much simpler, and also more in keeping with the principles of "responsive design," set the font family and size once, and then have all other elements inherit or adjust from this default setting. So I deleted repeat references to the font family wherever they were the same as the default. And for the body element, which adjusts somewhat based on media queries, I changed font size units to em.
Most typographers recommend line lengths between 45 and 90 characters, or between 2 and 3 *alphabets*. This commit sets #note-style to a max- width of 40em, which works out almost exactly to 3 alphabets at the widest. So it's still on the wider end of that recommended range. But because the text is narrower now, users won't have to jump so far when they move their eyes across the page as they read. This necessitated adjusting the position of #note-file-list to maintain the look of a paperclip attached to the notes page. However, it's possible that the file list could also look good if it were floated to the right of the note area, forming a third column for sufficiently large client displays. Maybe?
Using relative units (like em and percentages) instead of absolute units (like pixels and inches) is central to "responsive design." I think, if you can help it, usually the only element that needs fixed units should be the <body> font-size, and that should probably be adjusted based on display size using media queries. Another exception would be bitmap graphics, which don't scale as well. CSS lengths based on em will scale with the font size for different display devices, or scale with user browser stylesheets which change the default font size. And percentages will scale with the device display size. So that's what I've done here. Lengths of '0' are the same regardless of the unit, but in those cases I removed 'px' anyway because it might encourage other contributors to keep the pixel unit if they change that particular CSS property, which generally I don't think we want. ...By the way, what does the #drag style, in `note.styl`, apply to? I didn't change the lengths there to relative units because I couldn't figure out what it was; I could not make this element id appear anywhere in the markup in my test Cozy Notes app. I also did *not* edit the "Datepicker for Bootstrap" styles in `CNeditor.css`, though it was a little hard to tell where exactly the Bootstrap styles ended... If those styles are from Bootstrap, I figured you'd want to keep them the same as the upstream version. Right? I'd like if the .Th, .To, .Th, .Lh, .Lo, and .Lu styles -- the notes bullet points -- were indented a little more, but there would need to be fewer indentation levels, or else the largest indents would be wider than the #note-style container.
Before, the margin styles here were a little contradictory, since 'margin:' set the left and right margins to 0, but then 'margin-left' and 'margin-right' set them to percentages... What I really wanted to do next here was use a media query to change the positioning of the #nav block for smaller displays, so that smaller devices would get a single-column layout, saving precious screen space when actually editing their notes. However, the #nav position is set inline, so I can't make any changes from the stylesheet.
|
Thank you @Terrycloth for this big PR! I will review it soon. I think Cozy Notes require a lot more work to be fully responsive. Specially the left part. A quick and dirty fix could be to do the same a in Cozy Todos and add nav button that hides and show the menu on click. What do you think about it? |
|
Click to hide / show the nav bar sounds good to me too. |
|
It's been about a week now. Is there anything I can do to help move this pull request along? |
|
Sorry for the delay. I tried your change, the work on the text is interesting. I like the fact that fonts get bigger and that it doesn't fill the whole screen. But it's very opinionated, so I have to speak about it with the whole team. |
|
Hah, "opinionated" is probably right. I could take another look at the file attachment area. I have more edits planned anyway, but I wanted to discuss those, after this pull request is settled. I already know the file attachment area is not perfect yet, but could you tell me specifically what you think the problem is? Do you just not like its positioning relative to other elements in the page? Or is there a problem when there are several files attached? I'll admit I hadn't tested that. |
|
Ok here is a screenshot.
|
Hah, I just realized a couple days ago that there already is a button to hide the list of note pages, in that thing strip on the left side of the screen, between the notes list and the current note editor. It's a little hard to poke this narrow little strip on mobile devices, though...
Weird. What are the steps you take to duplicate this bug? When it happens, does the file list continue to hover over the scrollbar, or does it only last for a short time? I can't duplicate this bug for more than a split second -- it usually corrects itself as I'm scrolling the window, so I'm having a hard time using my browser dev tools to figure out what's going on there. ...Instead, I'm having an issue where the file list appears too far to the left when testing the client on narrower view ports. When I first load or refresh the page, it appears fine. When I scroll down it's still okay. But when I scroll back up, the file list is too far to the left. This bug happens pretty consistently. Apparently an inline style, set using the |
|
I think we should change the style of that widget and make it simpler to position. Would you be interested in finding it a new face ? I think it involves little programming, it's more about CSS. |
I agree. But the file list widget doesn't respond to CSS from the Stylus files because inline
You mean a font face? The file list widget currenlty uses Signika, just like everything in Cozy Notes. I personally think it would better to also make the file list's text color match the rest of the text, or at least make it closer to the text color of the rest of the Cozy Notes. But if you want to change the font for the notes editor, the file list widget, or both, Source Sans Pro is one of my favorite sans-serif fonts. |
Ok. I think we should make things more based on CSS. I mean not tweaked by JS.
Sorry for my bad english. I meant "Would you be interested in changing the widget look'n'feel (still not sure that it is the right word)?"
Thank you for the pointer. We would like to change the Cozy Fonts because of their bad way to deal with bold and italic. I will share that one with the team. |
Oh, I understand. Calling it the "face" could also work, but since we're talking about the particulars of design, I wasn't sure if you meant the more specific word "typeface" or something like that. Heh, your English is just fine; my French would be terrible. I'm certainly interested in helping out some more, and I can definitely take care of changes to the CSS. I just wanted to point out that some things -- such as the positioning of the file attachment widget -- can't be fixed with CSS until after the JS gets fixed. Since the things we've been talking about will require fixes to code which I have not edited in this pull request, can we either accept or close the pull request? I think it might be okay if the Master branch isn't perfect yet, because normally stable releases get pushed to separate branches, right? |
|
The master is the stable version. We apply continuous deployment principles, so we dont make real versioning. About the widget, we should change the positioning, it's too hard to maintain the way it is currently Making it full CSS is the right way to go. About the font face you, we can try the one you propose, the team like it. |
|
@Terrycloth How are you. Did you find time to work on this PR? |
|
Sorry, I haven't forgotten about this, nor given up. I've been learning CoffeeScript by doing some basic scripting with Eco in a DocPad site I'm building. I am still more confident in HTML/CSS and design than I am with programming. I still have plenty to learn. I might just be starting to understand enough to try to figure out a solution... but you could probably figure this out faster than I could. |
|
Ok, no problem. We are not focusing our work on the note application actually. So you have plenty of time to learn technologies. I will notify you when we'll work on it again. |
|
Sorry I've been so slow about this. Today is the first time I've been able to really sit down and look over the Cozy Notes code and try to figure out how it works. Now I'm having a problem starting the application again. It's been a while since I worked on this, so I'm having trouble figuring out what's wrong. I started CouchDB. That starts okay. I updated and then started the Cozy Data System. This seems to go okay. Then in another terminal, I go to Cozy Notes. I don't think there have been changes upstream since I began my pull request, so I just try to start it.
But I get this error:
|
|
What happens when you do? |
|
|
|
Sorry I gave you a wrong url. Could you try: |
|
|
I looks like your data system is broken. Could you update it and retry? |
|
cozy-data-system is already up-to-date. |
|
Ok but what is the output of the |
|
Hm, I get this output when running
|
|
I can't explain what is happening. Which version of Node.js are you running? |
|
Aaaa ok run A dependency is missing that's why your data system can't run properly. |
|
Ah! Okay, yes, that seems to fix it. I mean, aside from SELinux policies being a giant pain in the ass. I think now I can begin to begin. |
|
I think I've figured out how to make sure Working with the Stylus/CSS would also be a lot easier if we didn't change the position for
Otherwise, moving it to the right edge of the "page" will require like a dozen media queries that readjust the position at different display sizes. I was trying to do that at first, but the stylesheet gets pretty cluttered. |
|
Great! |
|
We'd talked about adding the Source Sans Pro font to this project, so that's the last thing I'm doing before updating this pull request. But I'm having a hard time figuring out how to link the font files in the stylesheet. There's like a dozen different Stylus and CSS files, and I'm not sure which to use as the starting point for a relative path to the font assets, and I don't think an absolute path for the app is working either... The font files are stored in Shouldn't an absolute path be something like this? |
|
Ah, never mind, I see. Apparently pages are served from |
As I noted in comments at the top of `base.styl`, the TrueType Font file was taken from the Google Fonts repository, and converted to other font formats using the Font Squirrel web service. Using this method will require settings bold and italic styles using the `font-family` CSS property instead of `font-weight` and `font-style` properties. Otherwise web browsers approximate their own version of bold and italic, instead of using the actual bold and italic font faces.
|
...Anyway, I think it's ready for you to take another look, if that wasn't clear. |
|
O ok. I'll give another try as soon as I can. Currently I'm focused on the email client release. |
|
Great work @Terrycloth, I really like your modification. I will share what you did with the whole team and then provide you with feedback. |
First steps toward a responsively designed client
|
Thank you again! |
|
yes, great contribution, with such improvements Cozy will be terrific ! Benjamin ANDRE 2014-12-11 13:43 GMT+01:00 Frank Rousseau [email protected]:
|
|
Whew, it's done! I'm glad that it's going well so far. I have some more code edits planned, but I'd like to discuss some of them before I start the work. Should I file GitHub Issues for these? What would you prefer? |
|
Yes, it's better if you open an issue first. |
Since these are mostly changes to design, I decided to take some screenshots...
Wide view
Medium view
Small view
The client still doesn't look great at very small sizes, but I talk about that in commit #47e7397. I tried to be very clear about my reasoning in the commits, so read those for more details.
I hope you like what I've done so far. Let me know if I messed up and edited the wrong files, or something needs to change.