Le 03/06/2016 à 05:45, Brynn a écrit :
For #1, I brought this up a long time ago. Well, something verysimilar (I think it was the h3 style I wanted to tweak, or maybe h4.....). I think the text styling needs an overhaul....or at least a tweak. Styles, and maybe even some classes or IDs, etc. too. The reply at that time was that we were considering a new website design in the foreseeable future. Although it seems like it stays in the distant future, and doesn't get closer. But the response was let's talk about it when we are getting a new design.
Sure, we could have a better design… Currently pages' content is a bit blunt. I don't think it's the right moment as the focus is on the 0.92 release. We could work on it in a few months if you want. I also have other work, such as translating that FLOSS manual…
There's a good chance that I put most of those empty paragraphsin there. The pages, and especially the pages with a lot of text, come across as imposing -- the wall of text, as they say. So I think they are the best we can do currently. I would not want to remove them until we have a good replacement. Do you think visitors to the site recognize that it's an empty paragraph? I don't see how they could know the difference, unless maybe if they are website designers
If they are a bit interested in style, typography or semantics like I am, they will notice that some headings have more space above them than others, and they will now that use of an empty paragraph to add more space in computer writing (most probably think it's a good use). They can also inspect the DOM (the document tree), of course.
Are the changes you suggest something that could be made easily?I'll have to refresh my html, and dig in a little bit, to understand specifically what you mention. In general, I understand what you're saying. But as far as the code itself, that's not in the front of my memory.
Yes, this is a very simple change, I can commit it within one minute. To understand what I meant, just right-click on a heading, and click the last menu item ‘Inspect element’. The inspector should appear, showing the document tree, and the tag/node for the heading you right-clicked will be selected. The styles that apply to the selected node are shown on the right. The style property I refer to is ‘margin’. In Firefox at least, you should see ‘main.css:line number’, indicating the place where the rule is defined. If you click on it, you'll go to the file.
If the changes can be easily inserted into the css, I'd say let'sdo it. But in this case, one change may lead to another and another. So maybe better to wait until everyone is focused on the new design? At least that's what I like to call "my simple-minded thoughts".
I think we can just do it because I'm very focused on the typography/semantics of the website and this is quite annoying…
((We (Sylvain and I) might not have had a formal introduction.So just for general info.... I do not have a local installation of the website. The only code I know is simple html, and my understanding of how websites work is fairly general and non-technical. (For example, this caching that's been mentioned so much lately -- I only understand the definition of "caching" and not what happens technically with the server.) I can add and edit the site content, using the django wysiwyg and/or the source/html. And I can join discussions about the content. But I hardly have any understanding of the programming side, with the trunks and commits and all.))
About the commits, the wiki has some info: http://wiki.inkscape.org/wiki/index.php/WebSite#Website_Development Then I joined the project and submitted two things: a fix for the ‘TOC nesting bug’ I detailed previously, and a fix in style to avoid overflow of preformatted blocks, using a scrollbar — see e.g.: https://inkscape.org/en/develop/debugging/ Therefore I had such an introduction… However I don't have a local installation of the website as the Python scripts don't work with me (I didn't emailed Martin about it yet, I'll do it), and I avoid using it as it is very hard to use with my ten-year slow computer. Fortunately I can often look carefully at what I wrote with autistic abilities, and prove its exactness. About caching, well, if you know the English word (I've only known the use in computing for a long time), this is it: the website server must compute many things to have the document it finally deliver to the visitor. To avoid redoing those same computations for each visitor who looks at the very same page, it caches some results to deliver them automatically, until the variables are effectively changed (in a perfect world). I don't have many details about what is cached for the Inkscape website but this principle is usually sufficient to understand everything. The ‘trunk’ is usually unique — it is the main development branch for a project. What is a branch? When we want to develop a feature, we might break the project. The next person who want to develop can't wait for our feature to be ready to start to develop their own one. So both developments are started from a state of the project that is known to work. Then we divide the development progress in two ‘branches’ and we will ‘merge’ them when both will be ready, to get a project with two new cool working features. Well, life with branches is much more rich and complex, but this is the basic idea. A ‘commit’ is the process of submitting a change to a branch. Am I clear?
Maybe Martin and/or Maren can give updated and/or more technicalanswer for that?
I should have enough…
For #2, I created the vast majority of what we have on the FAQpage today. (Well, the text anyway. It used to be straight html with anchors, but Martin installed a TOC plugin a few months ago. Now we can only edit the answers. If we need to add a new question, we have to ask Martin to do it.) I updated it from the old version, which I think is still existing in the wiki. (I made an updated version for the developers on the wiki too, but they apparently weren't interested in updating it. So it stays out of date.) Anyway, at that time, I had the option to have it all on one text block, or divided over 2 or more.
Thanks for your investment in the FAQs. I followed the story of the apparition of the TOC, don't you remember? About that TOC plugin, it seems you really didn't get it… even if we tried to explain. This plugin is a wonderful thing: it generates the anchors itself from the page contents. Then the writers don't have to mind the TOC when adding sections. You can totally add new questions to the FAQ without any problem. The anchor will appear in the TOC. You don't even have to set an ID to the heading (unless your heading has exactly the same title as another one). Just look at this script which is delivered with the website's pages: http://bazaar.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web/vie... Lines 22–26 say: when the document is ready, if there is a (single) #toc, then initialise anchors. The description of the way to do it is from line 35 to 83. Line 39 says: iterate over every heading in .wrapper. Lines 44–54 say: pick an id for the current heading. Line 69: add an anchor in the TOC as a list item leading to the heading.
For myself, it was better to have it all in one block. Most ofthe time, I worked on it locally in a text editor, and then pasted back in to save/publish. The text editor makes it so much easier, because it has the formatting, numbered lines, find/replace, etc. Ssooo much easier!!
Okay, but then, how can you edit the plugins? This is the main problem. Another thing that bothers me is the forced use of HTML entities by the CMS in the source code. In English you mostly have simple letters so that's not a problem, but e.g. in French you have many accented letters, and the very frequent ‘é’ becomes é and the source code becomes really difficult to read. There are also many apostrophs which become '. And many different accented letters: à è ê ô î â û ë ï and capital variants.
And so for myself, it's still better to have it in one block.And I would be happy to take on the responsibility to edit that page, if folks send me the info. However, on the other hand, I do understand that might not be the best scenario, logistically, for the project as a whole. So if everyone wants to break it up, I certainly would not object. I wonder if that can be done in a seamless way? Wouldn't there be a gap between blocks?
https://inkscape.org/en/download/?edit Do you see any gap? -- Sylvain