Questions concerning the website's content
Hi all,
I have three questions concerning the website's content.
1. For more space and better reading, headings (h2) are often preceded by an empty paragraph, e.g. in: * https://inkscape.org/en/learn/animation/ * https://inkscape.org/en/learn/faq/ This is true that pages are harder to read without that space; see: * https://inkscape.org/en/develop/getting-started/ * https://inkscape.org/en/contribute/testing/ However I have something against that practice of the empty paragraph; I feel it as wrong semantic. Couldn't we simply add more margin at the top of these headings? I suggest 4ex (it's currently 1.5ex). We could also increase the margin-top of 3rd-level headings (from 1.5ex to 2.5ex). Then we should remove those empty paragraphs (in the source form of <p> </p>).
2. It is quite hard to find the part we want when editing the FAQ; could we subdivide the only text plugin in several text plugins, one for each section?
3. Is it possible to translate the two following pages, or will it be made possible? * https://inkscape.org/fr/apropos/captures/ * https://inkscape.org/fr/teams/ (and why not teams themselves)
Everyone may give their opinion about the first two questions; the last one is for those who know…
Thank you, -- Sylvain
Hi Sylvain, For #1, I brought this up a long time ago. Well, something very similar (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. There's a good chance that I put most of those empty paragraphs in 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 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. If the changes can be easily inserted into the css, I'd say let's do 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". ((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.)) Maybe Martin and/or Maren can give updated and/or more technical answer for that?
For #2, I created the vast majority of what we have on the FAQ page 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. For myself, it was better to have it all in one block. Most of the 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!! 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?
I can't answer #3.
All best, brynn
-------------------------------------------------- From: "Sylvain Chiron" <chironsylvain@...102...> Sent: Thursday, June 02, 2016 5:07 PM To: "Inkscape translators" inkscape-translator@lists.sourceforge.net; "Inkscape Docs" inkscape-docs@lists.sourceforge.net Subject: [Inkscape-docs] Questions concerning the website's content
Hi all,
I have three questions concerning the website's content.
- For more space and better reading, headings (h2) are often preceded
by an empty paragraph, e.g. in:
This is true that pages are harder to read without that space; see:
However I have something against that practice of the empty paragraph; I feel it as wrong semantic. Couldn't we simply add more margin at the top of these headings? I suggest 4ex (it's currently 1.5ex). We could also increase the margin-top of 3rd-level headings (from 1.5ex to 2.5ex). Then we should remove those empty paragraphs (in the source form of
<p> </p>).
- It is quite hard to find the part we want when editing the FAQ; could
we subdivide the only text plugin in several text plugins, one for each section?
- Is it possible to translate the two following pages, or will it be
made possible?
- https://inkscape.org/fr/apropos/captures/
- https://inkscape.org/fr/teams/ (and why not teams themselves)
Everyone may give their opinion about the first two questions; the last one is for those who know…
Thank you,
Sylvain
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs
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
On Fri, 2016-06-03 at 08:27 +0200, Sylvain Chiron wrote:
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 can say that you should consider any new website design to be frozen and you can sort on any part of the design for the website for incremental improvements. I've been ding that for the past few months too.
If you change H1, h2, h3 styles, just remember to be specific in your css and say .page h1 { ... }, so that the styles won't change non-cms content pages. (unless that's what you want to do of course)
You can email me updated css files if you're not sure about patching or merge requests.
Martin,
Le 03/06/2016 à 17:28, Martin Owens a écrit :
I can say that you should consider any new website design to be frozen and you can sort on any part of the design for the website for incremental improvements. I've been ding that for the past few months too.
Do you mean ‘shouldn't’? That's OK.
If you change H1, h2, h3 styles, just remember to be specific in your css and say .page h1 { ... }, so that the styles won't change non-cms content pages. (unless that's what you want to do of course)
The current CSS rule is only h1, h2, h3… without any ancestor specified. I think there are no headings elsewhere. I'll alter the current rules directly.
You can email me updated css files if you're not sure about patching or merge requests.
I should achieve that myself, but thank you anyway.
I'll talk with Brynn. -- Sylvain
Dear Sylvain,
Am 04.06.2016 um 16:55 schrieb Sylvain Chiron:
Le 03/06/2016 à 17:28, Martin Owens a écrit :
I can say that you should consider any new website design to be frozen and you can sort on any part of the design for the website for incremental improvements. I've been ding that for the past few months too.
Do you mean ‘shouldn't’? That's OK.
- Sorry for chiming in, Martin.
Sylvain, what he means is that there are no current efforts going on for a revolutionary redesign of the page. But we can make small changes to improve the current design.
If you change H1, h2, h3 styles, just remember to be specific in your css and say .page h1 { ... }, so that the styles won't change non-cms content pages. (unless that's what you want to do of course)
The current CSS rule is only h1, h2, h3… without any ancestor specified. I think there are no headings elsewhere. I'll alter the current rules directly.
- Please make the new rules more specific. Your changes will change *all* h2 and h3 on the website.
We do only want to change those inside the cms pages. All other h2 and h3 headings (unless there aren't any? You could check that first, to see if this is necessary) must stay the same.
So this means as a general rule you'd need to - check if there are other parts in the code that will be concerned by a change (hint: there are lots of them! Use search/grep on all .html files with '<h2' as query) anywhere in our templates, and if so: - add separate rules, or make sure it looks okay first with all pages that are concerned by the change.
In this case, I think we'll need two new rules that set the margins for cms headings differently than for the usual headings.
Kind Regards, Maren
Le 04/06/2016 à 17:44, Maren Hachmann a écrit :
Am 04.06.2016 um 16:55 schrieb Sylvain Chiron:
Le 03/06/2016 à 17:28, Martin Owens a écrit :
I can say that you should consider any new website design to be frozen and you can sort on any part of the design for the website for incremental improvements. I've been ding that for the past few months too.
Do you mean ‘shouldn't’? That's OK.
- Sorry for chiming in, Martin.
Sylvain, what he means is that there are no current efforts going on for a revolutionary redesign of the page. But we can make small changes to improve the current design.
Okay… Strange language. That's understood.
We do only want to change those inside the cms pages. All other h2 and h3 headings (unless there aren't any? You could check that first, to see if this is necessary) must stay the same.
There are others actually, but they all redefine their own margin and size. Wait… OK, you're right, there are many headings elsewhere — :). There is no overriding rule here: https://inkscape.org/en/*users/chat/ So I'll make different rules: ‘.wrapper h2’ and ‘.wrapper h3’.
Le 03/06/2016 à 19:48, Maren Hachmann a écrit :
If you do make this change, it would help if you could also take some time to remove (at least a few of) the paragraphs when the fix has been released, so the pages will not look weird due to huge gaps between the headings and the following texts.
I don't think there's a need to wait. I'll remove the paragraphs right now except in the FAQ for which I'll wait.
- It is quite hard to find the part we want when editing the FAQ; could
we subdivide the only text plugin in several text plugins, one for each section?
- That's an option. Before we continue to discuss if it is to be
implemented, please research if those plugins must then also be added to all translations.
I think there's no link between text plugins in different languages. Optionnally, only translators who want several text plugins could subdivide.
It may be that missing plugins will automatically be substituted by their English counterparts (I think due to a bug in current django, this does not happen, but as soon as they fix the bug, there could be a problem - there was something about this in their bug tracker, I seem to remember).
You mean that if we try to take the links from a text plugin to another, we may get the English links (as the plugins will remain childs of the initial text plugin)? However… If we try to move the plugins from a text plugin to another, it will simply remove the plugins' data and the plugins won't exist in the second text plugin (I just tried on the sandbox)… Thus it would be a very difficult task to subdivide as I thought…
I could imagine splitting the FAQ into its major 7 sections, but having a single one for each question would make editing a bit annoying (also it's too much editing work to put that change in, as copy-paste for links or images between plugins might not work as expected).
Yes, I was talking about a splitting for the major sections. -- Sylvain
Dear Sylvain,
Am 04.06.2016 um 18:40 schrieb Sylvain Chiron:
Le 03/06/2016 à 19:48, Maren Hachmann a écrit :
If you do make this change, it would help if you could also take some time to remove (at least a few of) the paragraphs when the fix has been released, so the pages will not look weird due to huge gaps between the headings and the following texts.
I don't think there's a need to wait. I'll remove the paragraphs right now except in the FAQ for which I'll wait.
- I agree. Thank you for starting out on this!
It may be that missing plugins will automatically be substituted by their English counterparts (I think due to a bug in current django, this does not happen, but as soon as they fix the bug, there could be a problem - there was something about this in their bug tracker, I seem to remember).
- I just had time to look up the bug I was thinking of. Fortunately, it was about specific *nested* plugins not showing up when the translation doesn't have any plugins, so it's not relevant here.
However… If we try to move the plugins from a text plugin to another, it will simply remove the plugins' data and the plugins won't exist in the second text plugin (I just tried on the sandbox)… Thus it would be a very difficult task to subdivide as I thought…
- Yes, that's what I meant by "as copy-paste for links or images between plugins might not work as expected". Nested plugins are saved as children of other plugins. When removed from their original place, and pasted into another one, I assume that they will be gone, because they are deleted from their original place.
I could imagine splitting the FAQ into its major 7 sections, but having a single one for each question would make editing a bit annoying (also it's too much editing work to put that change in, as copy-paste for links or images between plugins might not work as expected).
Yes, I was talking about a splitting for the major sections.
- So I agree that's a lot of work. Only you can decide if it would be worth the gain for you.
I can work with both situations, and I think Brynn can, too. It might make work a tiny bit faster, but not enough so that I would want to do the splitting myself. Maybe there's something else that would profit from our time investment more than this? We've got enough bug reports for inkscape-web to have work for a couple of months...
You seem to like javascript stuff, so maybe the inbox problems or the TOC customization could profit from your work.
Before you start working on any bug, please add a comment there, telling the others that you plan to work on it (so we don't work on the same bug at the same time), and also sketch roughly what you'd do to fix it. We can then give feedback, or add some more info to the report before you start working on it. Sometimes, things have changed since the bug was first reported, or we may know or plan something that you cannot know about.
Kind Regards, Maren
Hi Everyone, Well if we can make small changes, could we possibly make the h3 style to look like it's bigger than h4? Just making it bold would be fine with me. Or make h4 not bold would work as well. The reason for this is that I think h4 overtakes h3 on a page, and makes it hard to understand the intended organization of the page where it's used. Also, and I know this idea probably goes against current website design styles (in general). But would it be possible to have h4, h5 and h6 indented? It's just the current left justification of Everything on a page makes it hard to read - very imposing.
Thanks, brynn
-------------------------------------------------- From: "Maren Hachmann" <maren@...68...> Sent: Saturday, June 04, 2016 9:44 AM To: "Inkscape-Docs" inkscape-docs@lists.sourceforge.net Subject: Re: [Inkscape-docs] Questions concerning the website's content
Dear Sylvain,
Am 04.06.2016 um 16:55 schrieb Sylvain Chiron:
Le 03/06/2016 à 17:28, Martin Owens a écrit :
I can say that you should consider any new website design to be frozen and you can sort on any part of the design for the website for incremental improvements. I've been ding that for the past few months too.
Do you mean ‘shouldn't’? That's OK.
- Sorry for chiming in, Martin.
Sylvain, what he means is that there are no current efforts going on for a revolutionary redesign of the page. But we can make small changes to improve the current design.
If you change H1, h2, h3 styles, just remember to be specific in your css and say .page h1 { ... }, so that the styles won't change non-cms content pages. (unless that's what you want to do of course)
The current CSS rule is only h1, h2, h3… without any ancestor specified. I think there are no headings elsewhere. I'll alter the current rules directly.
- Please make the new rules more specific. Your changes will change
*all* h2 and h3 on the website.
We do only want to change those inside the cms pages. All other h2 and h3 headings (unless there aren't any? You could check that first, to see if this is necessary) must stay the same.
So this means as a general rule you'd need to
- check if there are other parts in the code that will be concerned by a
change (hint: there are lots of them! Use search/grep on all .html files with '<h2' as query) anywhere in our templates, and if so:
- add separate rules, or make sure it looks okay first with all pages
that are concerned by the change.
In this case, I think we'll need two new rules that set the margins for cms headings differently than for the usual headings.
Kind Regards, Maren
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs
Hi Brynn,
Am 05.06.2016 um 02:47 schrieb Brynn:
Hi Everyone, Well if we can make small changes, could we possibly make the h3 style to look like it's bigger than h4? Just making it bold would be fine with me. Or make h4 not bold would work as well. The reason for this is that I think h4 overtakes h3 on a page, and makes it hard to understand the intended organization of the page where it's used.
- Just turned this into a bug report: https://bugs.launchpad.net/inkscape-web/+bug/1589280
Also, and I know this idea probably goes against current websitedesign styles (in general). But would it be possible to have h4, h5 and h6 indented? It's just the current left justification of Everything on a page makes it hard to read - very imposing.
- We could review the style of those while we take a look at the other headings. Added that to the report.
But first we'd have to make sure those styles will only be used for CMS pages.
Regards, Maren
Ok, thanks Maren.
But first we'd have to make sure those styles will only be used for CMS pages.
I don't quite understand that part. But I trust that you and Sylvain and Martin will do whatever is best :-)
Thanks, brynn
-------------------------------------------------- From: "Maren Hachmann" <maren@...68...> Sent: Sunday, June 05, 2016 11:04 AM To: inkscape-docs@lists.sourceforge.net Subject: Re: [Inkscape-docs] Questions concerning the website's content
Hi Brynn,
Am 05.06.2016 um 02:47 schrieb Brynn:
Hi Everyone, Well if we can make small changes, could we possibly make the h3 style to look like it's bigger than h4? Just making it bold would be fine with me. Or make h4 not bold would work as well. The reason for this is that I think h4 overtakes h3 on a page, and makes it hard to understand the intended organization of the page where it's used.
- Just turned this into a bug report:
https://bugs.launchpad.net/inkscape-web/+bug/1589280
Also, and I know this idea probably goes against current websitedesign styles (in general). But would it be possible to have h4, h5 and h6 indented? It's just the current left justification of Everything on a page makes it hard to read - very imposing.
- We could review the style of those while we take a look at the other
headings. Added that to the report.
But first we'd have to make sure those styles will only be used for CMS pages.
Regards, Maren
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ Inkscape-docs mailing list Inkscape-docs@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-docs
About that TOC plugin, it seems you really didn't get it… even if we tried to explain.
Yes, I understand it now. Apparently you and Maren and Martin can add new questions, as well as answers. But I can't add new questions - only answers, because I can't edit the code.
The TOC is frustrating for me, because I originally typed/edited everything on the page (by writing the html directly, which I find enjoyable). But like so many other parts of the website cms/django, it very much limits what I am able to do. Now, except for minor edits, here and there, all I can contribute is comments about the website content. By now, most of the website is controlled from a level that I don't have access to, and couldn't use it, even if I did.
Okay, but then, how can you edit the plugins? This is the main problem.
When I first created that page, the only plugin available (to me) was Links. At first, I didn't use it at all, because it didn't work. But later, we found the problem was one of my Firefox plugins that blocks the referrer header. So then, I was able to fix all the links.
All best, brynn
-------------------------------------------------- From: "Sylvain Chiron" <chironsylvain@...102...> Sent: Friday, June 03, 2016 12:27 AM To: "Brynn" <brynn@...78...> Cc: "Inkscape translators" inkscape-translator@lists.sourceforge.net; "Inkscape Docs" inkscape-docs@lists.sourceforge.net Subject: Re: [Inkscape-docs] Questions concerning the website's content
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
Hi Sylvain,
Am 03.06.2016 um 01:07 schrieb Sylvain Chiron:
- For more space and better reading, headings (h2) are often preceded
by an empty paragraph,
- as suggested by Martin, feel free to fix this. As you're still making your first commits to the repo, for any bigger changes than this simple CSS fix, please make a branch and a merge request, so we can share some feedback.
If you do make this change, it would help if you could also take some time to remove (at least a few of) the paragraphs when the fix has been released, so the pages will not look weird due to huge gaps between the headings and the following texts.
- It is quite hard to find the part we want when editing the FAQ; could
we subdivide the only text plugin in several text plugins, one for each section?
- That's an option. Before we continue to discuss if it is to be implemented, please research if those plugins must then also be added to all translations.
It may be that missing plugins will automatically be substituted by their English counterparts (I think due to a bug in current django, this does not happen, but as soon as they fix the bug, there could be a problem - there was something about this in their bug tracker, I seem to remember).
I could imagine splitting the FAQ into its major 7 sections, but having a single one for each question would make editing a bit annoying (also it's too much editing work to put that change in, as copy-paste for links or images between plugins might not work as expected).
- Is it possible to translate the two following pages, or will it be
made possible?
- https://inkscape.org/fr/apropos/captures/
- https://inkscape.org/fr/teams/ (and why not teams themselves)
- See https://bugs.launchpad.net/inkscape-web/+bug/1542925 for an explanation and a feature request.
Kind Regards, Maren
participants (4)
-
Brynn -
Maren Hachmann -
Martin Owens -
Sylvain Chiron