Re: [libreoffice-design] Future libreoffice.org web page: design request
Hi Christoph, Love what you guys are doing here, looks great. Cheers, Andrew On Fri, Sep 16, 2011 at 5:54 PM, Christoph Noack christ...@dogmatux.comwrote: Hi all, after my rather lengthly explanation yesterday, here is an structural example (based on See's design) of how it could look like: https://picasaweb.google.com/lh/photo/PLZvWTs1NiL_w3auPyfUjA?feat=directlink Cheers, Christoph Am Freitag, den 16.09.2011, 00:40 +0200 schrieb Christoph Noack: Good evening Loic! 18 minutes to go before tomorrow gets today ;-) Am Mittwoch, den 14.09.2011, 12:57 +0200 schrieb Loic Dachary: On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - [...] I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? Yep, otherwise the progress indicator on the left side isn't that much needed ... the Next approach helps to slice the required information in reasonable chunks being (hopefully) more understandable, and it ensures a constant screen height. Of course, there are other solutions ... but not knowing exactly the workflow and the questions, I assumed this to work best. If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work Okay, there are some assumptions on my side, so let's go through some use cases. I lack the time to do the example graphics, so I hope some descriptions are sufficient to understand it. I hope something like that can be done technically ... The problem: * We have procedure of several steps, * the procedure might be tree like instead of linear, * (future) steps may be added when working with the wizard * (future) steps may also be removed when working with the wizard, * the user might choose to go back and to change options, * selected steps need to be checked for consistency/correctness, * assumption: the user can only continue to the next step, if the current step (and the steps before) are valid. So, we need to introduce some states for each step (the stuff in the squared brackets will be used for further description): * not available * [ 1 ] a step with number 1 not worked on yet * [ 1 ] a step with number 1 already currently being worked on * [ *1* ] a step with number 1 already finished * [*1*] a step with number 1 already finished (before), currently being worked on (because user visits it again) * [ ... ] a placeholder for one or more steps not worked on yet and not known yet (because we have to implement the tree like procedure) * [ --- ] a step not worked on yet after [ ... ]; step number cannot be calculated, but the action is known Example: [ *1* ] Preparation [ *2* ] Component [ 3 ] Sub-Component [ 4 ] Version [ ... ] [ --- ] Description [ --- ] Submit [ --- ] Attachment It might look overly complex, but I'm sure you know such indications from websites and other software. Let's dig into it ... the use cases (each of the cases starts with the conditions in the example above). Current: The user works on step 3, he successfully completed steps 1 and 2. The next step 4 requires to chose the LibO version - but this may have impact on insert_reason_here, so we may need additional step(s) [...]. Therefore, we skip the numbers for Description, Submit and Attachment. Go back: User goes back to step 2 but doesn't change anything. * [ *1* ] Preparation * [*2*] Component * [ 3 ] Sub-Component * [ 4 ] Version * [ ... ] * [ --- ] Description * [ --- ] Submit * [ --- ] Attachment Note: If the user changes the component in step 2, then (in our constructed case) all future steps are dependent and get set to not worked on yet. Go forward: The user choses to have a look at one of the steps not yet done. Here we have two alternatives (technical constraints will decide here): 1. We don't offer to go there (inactive button) 2. We show the BSA page, but the whole page content is inactive Add steps: The user selects the sub-component in step 3 and confirms. Now we are sure that we need two additional steps - the workflow is linear now. So we can add step 5 and 6, and the remaining steps can get numbers as well: * [ *1* ] Preparation * [ *2* ]
Re: [libreoffice-design] Future libreoffice.org web page: design request
Hi all, after my rather lengthly explanation yesterday, here is an structural example (based on See's design) of how it could look like: https://picasaweb.google.com/lh/photo/PLZvWTs1NiL_w3auPyfUjA?feat=directlink Cheers, Christoph Am Freitag, den 16.09.2011, 00:40 +0200 schrieb Christoph Noack: Good evening Loic! 18 minutes to go before tomorrow gets today ;-) Am Mittwoch, den 14.09.2011, 12:57 +0200 schrieb Loic Dachary: On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - [...] I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? Yep, otherwise the progress indicator on the left side isn't that much needed ... the Next approach helps to slice the required information in reasonable chunks being (hopefully) more understandable, and it ensures a constant screen height. Of course, there are other solutions ... but not knowing exactly the workflow and the questions, I assumed this to work best. If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work Okay, there are some assumptions on my side, so let's go through some use cases. I lack the time to do the example graphics, so I hope some descriptions are sufficient to understand it. I hope something like that can be done technically ... The problem: * We have procedure of several steps, * the procedure might be tree like instead of linear, * (future) steps may be added when working with the wizard * (future) steps may also be removed when working with the wizard, * the user might choose to go back and to change options, * selected steps need to be checked for consistency/correctness, * assumption: the user can only continue to the next step, if the current step (and the steps before) are valid. So, we need to introduce some states for each step (the stuff in the squared brackets will be used for further description): * not available * [ 1 ] a step with number 1 not worked on yet * [ 1 ] a step with number 1 already currently being worked on * [ *1* ] a step with number 1 already finished * [*1*] a step with number 1 already finished (before), currently being worked on (because user visits it again) * [ ... ] a placeholder for one or more steps not worked on yet and not known yet (because we have to implement the tree like procedure) * [ --- ] a step not worked on yet after [ ... ]; step number cannot be calculated, but the action is known Example: [ *1* ] Preparation [ *2* ] Component [ 3 ] Sub-Component [ 4 ] Version [ ... ] [ --- ] Description [ --- ] Submit [ --- ] Attachment It might look overly complex, but I'm sure you know such indications from websites and other software. Let's dig into it ... the use cases (each of the cases starts with the conditions in the example above). Current: The user works on step 3, he successfully completed steps 1 and 2. The next step 4 requires to chose the LibO version - but this may have impact on insert_reason_here, so we may need additional step(s) [...]. Therefore, we skip the numbers for Description, Submit and Attachment. Go back: User goes back to step 2 but doesn't change anything. * [ *1* ] Preparation * [*2*] Component * [ 3 ] Sub-Component * [ 4 ] Version * [ ... ] * [ --- ] Description * [ --- ] Submit * [ --- ] Attachment Note: If the user changes the component in step 2, then (in our constructed case) all future steps are dependent and get set to not worked on yet. Go forward: The user choses to have a look at one of the steps not yet done. Here we have two alternatives (technical constraints will decide here): 1. We don't offer to go there (inactive button) 2. We show the BSA page, but the whole page content is inactive Add steps: The user selects the sub-component in step 3 and confirms. Now we are sure that we need two additional steps - the workflow is linear now. So we can add step 5 and 6, and the remaining steps can get numbers as well: * [ *1* ] Preparation * [ *2* ] Component * [ *3* ] Sub-Component * [ 4 ] Version * [ 5 ] Whateveroption * [ 6 ] Evenanotherwhateveroption * [ 7 ] Description * [ 8 ] Submit * [ 9 ] Attachment Note: This behavior is similar
Re: [libreoffice-design] Future libreoffice.org web page: design request
Good evening Loic! 18 minutes to go before tomorrow gets today ;-) Am Mittwoch, den 14.09.2011, 12:57 +0200 schrieb Loic Dachary: On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - [...] I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? Yep, otherwise the progress indicator on the left side isn't that much needed ... the Next approach helps to slice the required information in reasonable chunks being (hopefully) more understandable, and it ensures a constant screen height. Of course, there are other solutions ... but not knowing exactly the workflow and the questions, I assumed this to work best. If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work Okay, there are some assumptions on my side, so let's go through some use cases. I lack the time to do the example graphics, so I hope some descriptions are sufficient to understand it. I hope something like that can be done technically ... The problem: * We have procedure of several steps, * the procedure might be tree like instead of linear, * (future) steps may be added when working with the wizard * (future) steps may also be removed when working with the wizard, * the user might choose to go back and to change options, * selected steps need to be checked for consistency/correctness, * assumption: the user can only continue to the next step, if the current step (and the steps before) are valid. So, we need to introduce some states for each step (the stuff in the squared brackets will be used for further description): * not available * [ 1 ] a step with number 1 not worked on yet * [ 1 ] a step with number 1 already currently being worked on * [ *1* ] a step with number 1 already finished * [*1*] a step with number 1 already finished (before), currently being worked on (because user visits it again) * [ ... ] a placeholder for one or more steps not worked on yet and not known yet (because we have to implement the tree like procedure) * [ --- ] a step not worked on yet after [ ... ]; step number cannot be calculated, but the action is known Example: [ *1* ] Preparation [ *2* ] Component [ 3 ] Sub-Component [ 4 ] Version [ ... ] [ --- ] Description [ --- ] Submit [ --- ] Attachment It might look overly complex, but I'm sure you know such indications from websites and other software. Let's dig into it ... the use cases (each of the cases starts with the conditions in the example above). Current: The user works on step 3, he successfully completed steps 1 and 2. The next step 4 requires to chose the LibO version - but this may have impact on insert_reason_here, so we may need additional step(s) [...]. Therefore, we skip the numbers for Description, Submit and Attachment. Go back: User goes back to step 2 but doesn't change anything. * [ *1* ] Preparation * [*2*] Component * [ 3 ] Sub-Component * [ 4 ] Version * [ ... ] * [ --- ] Description * [ --- ] Submit * [ --- ] Attachment Note: If the user changes the component in step 2, then (in our constructed case) all future steps are dependent and get set to not worked on yet. Go forward: The user choses to have a look at one of the steps not yet done. Here we have two alternatives (technical constraints will decide here): 1. We don't offer to go there (inactive button) 2. We show the BSA page, but the whole page content is inactive Add steps: The user selects the sub-component in step 3 and confirms. Now we are sure that we need two additional steps - the workflow is linear now. So we can add step 5 and 6, and the remaining steps can get numbers as well: * [ *1* ] Preparation * [ *2* ] Component * [ *3* ] Sub-Component * [ 4 ] Version * [ 5 ] Whateveroption * [ 6 ] Evenanotherwhateveroption * [ 7 ] Description * [ 8 ] Submit * [ 9 ] Attachment Note: This behavior is similar for removing steps. Note: The bullet points show the most simple linear use case we will implement now, I assume. I hope that explains most of the behavior - I hope some of the basic ideas came through (and hopefully I did not make too many mistakes). Let's see how to transform that into visual feedback ... using [1] as a reference. * [ 1 ] shown small number in small circle, semi-transparent
Re: [libreoffice-design] Future libreoffice.org web page: design request
On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - replacing the file you've uploaded for me (thanks!): Hi, http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Web_design Comments on the new version: * It is still a draft ... * I refined the structure so that it matches better with the design proposal you've send to me (navigation on the left side, more dominant header). * Added a few more steps and thought a bit how things could be explained in a rather user-friendly language (whereas I tried to be as understandable as possible until the bug report assistant is entered). I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work * I've tried to follow your current workflow, added snippets provided by Michael and Rainer ... and considered getting help and joining a user survey. However, the essential part bug report would also work stand-alone. * The structure contains a lot of Full Description elements - added for scalability reasons, if the normal field size is too small. So, they can be removed if not needed. I'm not sure what you're referring to. Are there the Read on... links ? * Personally, I think the structure is just a contain to add the real workflow like the one by Michael. I don't know what's currently planned, but it would provide more guidance (asking for crashes, rendering fidelity ...). I suppose the bug report will eventually be a tree of decisions. Because of that it won't be possible to display all the steps in advance on the leftmost menu. But for now it is and changing later should not be too much of a problem. * I've left some placeholders due to missing time and missing knowledge, here it would be great if the others could jump in to help us finalize the work. * I might have missed some (or many) details, since I've tried to avoid reading further mails this evening ... aehm ... night :-) * And, grr, already found some caption mistakes after uploading ... but that doesn't affect the concept. Feedback appreciated ... :-) There are two technical issues that impact the user experience. a) the fact that the bug assistant cannot register a new user (this has been covered extensively already and there is nothing to add, I think) b) the fact that bugzilla only allows for an attachment once the bug is created. It means that no attachment can be required to the user *before* the bug is submitted. Of course, the bug assistant could hide this from the user. For instance the bug could be submitted just before the first attachment is required from him. However, since the goal of the bug submission assistant is to reduce the number of bugs that are poorly described, this should be done only after there is enough information in the bug report, so that even if the user gives up before attaching the document the created bug report is useable. It is possible to workaround this limitation (attachments). However that implies the creation and maintainance of a server side temporary cache for attachments. This is not complex, but it adds a new layer to the bug submission assistant. It currently is client side only and there are no server side part. I'm happy to implement it if you think it's worth the trouble but I wanted to let you know what it entails, technically. Since this mail is send to the QA list / Design list as well, I'll keep most of the discussion we had so far. I'm expecting proposals from a web designer participating in the following contest http://99designs.com/web-design/contests/bug-submission-web-form-design-wanted-libreoffice-95945/brief The work you've done with http://wiki.documentfoundation.org/File:BSAinteraction.png makes it a lot easier for them to understand what's going on. Much easier than playing with the live example. Cheers Am Dienstag, den 13.09.2011, 10:01 +0200 schrieb Loic Dachary: On 09/13/2011 12:44 AM, Christoph Noack wrote: [...] So I've started to read most of the specs lying around and tried to understand the motivation by Rainer and Michael. Next, I've tried you bug report assistant and read the mails discussing that topic on the mailing list. Finally, I've tried to come up with my own point-of-view in a mockup (which is far from being completed):
Re: [libreoffice-design] Future libreoffice.org web page: design request
Hi all! Short mobile reply: most of the questions can be resolved easily, but it requires some compromises and some interactive handling of the BSA. But not today... Note: all interested people should have a look at the libo-qa list for technical updates. See you! Christoph -- Sent via mobile... Loic Dachary l...@dachary.org schrieb: On 09/14/2011 01:01 AM, Christoph Noack wrote: Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - replacing the file you've uploaded for me (thanks!): Hi, http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Web_design Comments on the new version: * It is still a draft ... * I refined the structure so that it matches better with the design proposal you've send to me (navigation on the left side, more dominant header). * Added a few more steps and thought a bit how things could be explained in a rather user-friendly language (whereas I tried to be as understandable as possible until the bug report assistant is entered). I noticed the next button and the fact that each step would be displayed on its own. I assume that the user would be able to click on a previous step to amend its choice. Is that right ? If it is the case, let say (s)he changes the component. How would (s)he be notified that a new subcomponent must be chosen ? In the case of a single page displaying all the information, I though there would be an error message + red border around the missing field. With a multipage display I can't picture how it would work * I've tried to follow your current workflow, added snippets provided by Michael and Rainer ... and considered getting help and joining a user survey. However, the essential part bug report would also work stand-alone. * The structure contains a lot of Full Description elements - added for scalability reasons, if the normal field size is too small. So, they can be removed if not needed. I'm not sure what you're referring to. Are there the Read on... links ? * Personally, I think the structure is just a contain to add the real workflow like the one by Michael. I don't know what's currently planned, but it would provide more guidance (asking for crashes, rendering fidelity ...). I suppose the bug report will eventually be a tree of decisions. Because of that it won't be possible to display all the steps in advance on the leftmost menu. But for now it is and changing later should not be too much of a problem. * I've left some placeholders due to missing time and missing knowledge, here it would be great if the others could jump in to help us finalize the work. * I might have missed some (or many) details, since I've tried to avoid reading further mails this evening ... aehm ... night :-) * And, grr, already found some caption mistakes after uploading ... but that doesn't affect the concept. Feedback appreciated ... :-) There are two technical issues that impact the user experience. a) the fact that the bug assistant cannot register a new user (this has been covered extensively already and there is nothing to add, I think) b) the fact that bugzilla only allows for an attachment once the bug is created. It means that no attachment can be required to the user *before* the bug is submitted. Of course, the bug assistant could hide this from the user. For instance the bug could be submitted just before the first attachment is required from him. However, since the goal of the bug submission assistant is to reduce the number of bugs that are poorly described, this should be done only after there is enough information in the bug report, so that even if the user gives up before attaching the document the created bug report is useable. It is possible to workaround this limitation (attachments). However that implies the creation and maintainance of a server side temporary cache for attachments. This is not complex, but it adds a new layer to the bug submission assistant. It currently is client side only and there are no server side part. I'm happy to implement it if you think it's worth the trouble but I wanted to let you know what it entails, technically. Since this mail is send to the QA list / Design list as well, I'll keep most of the discussion we had so far. I'm expecting proposals from a web designer participating in the following contest http://99designs.com/web-design/contests/bug-submission-web-form-design-wanted-libreoffice-95945/brief The work you've done with http://wiki.documentfoundation.org/File:BSAinteraction.png makes it a lot easier for them to understand what's going on. Much easier than playing with the live example. Cheers Am Dienstag, den 13.09.2011, 10:01 +0200 schrieb Loic Dachary: On 09/13/2011 12:44 AM, Christoph Noack wrote: [...] So I've started to read most of the specs lying around and tried to understand the motivation by Rainer and Michael. Next, I've tried you bug report assistant and read the mails
Re: [libreoffice-design] Future libreoffice.org web page: design request
Hi Loic, hi all! I've refined the interaction design a bit and uploaded it to the wiki - replacing the file you've uploaded for me (thanks!): http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Web_design Comments on the new version: * It is still a draft ... * I refined the structure so that it matches better with the design proposal you've send to me (navigation on the left side, more dominant header). * Added a few more steps and thought a bit how things could be explained in a rather user-friendly language (whereas I tried to be as understandable as possible until the bug report assistant is entered). * I've tried to follow your current workflow, added snippets provided by Michael and Rainer ... and considered getting help and joining a user survey. However, the essential part bug report would also work stand-alone. * The structure contains a lot of Full Description elements - added for scalability reasons, if the normal field size is too small. So, they can be removed if not needed. * Personally, I think the structure is just a contain to add the real workflow like the one by Michael. I don't know what's currently planned, but it would provide more guidance (asking for crashes, rendering fidelity ...). * I've left some placeholders due to missing time and missing knowledge, here it would be great if the others could jump in to help us finalize the work. * I might have missed some (or many) details, since I've tried to avoid reading further mails this evening ... aehm ... night :-) * And, grr, already found some caption mistakes after uploading ... but that doesn't affect the concept. Feedback appreciated ... :-) Since this mail is send to the QA list / Design list as well, I'll keep most of the discussion we had so far. Am Dienstag, den 13.09.2011, 10:01 +0200 schrieb Loic Dachary: On 09/13/2011 12:44 AM, Christoph Noack wrote: [...] So I've started to read most of the specs lying around and tried to understand the motivation by Rainer and Michael. Next, I've tried you bug report assistant and read the mails discussing that topic on the mailing list. Finally, I've tried to come up with my own point-of-view in a mockup (which is far from being completed): https://picasaweb.google.com/lh/photo/w31yhEvxH3xkTt1YYwvjkA?feat=directlink It's a great illustration of what I have in mind, except for the left part which is outside the scope of the bug submission assistant (I hope ;-). I wish I would be able to do such nice schematics. Thanks :-) A first feedback from your side would be great! Some comments: * The intermediate page that allows people to provide feedback via different methods is something I'd like to have for our users. To me, it seems less important for your work I guess. yes. * I assumed that the content is embedded into some other website, e.g. the LibreOffice website. yes, in an iframe https://www.libreoffice.org/get-help/bugTest/?stage=Stage * The first step is a mixture of Michael's proposal and the one I've made ago ... selecting the main components via buttons (or whatever can be done) and offering a container (or whatever...) to provide a full list if people are able to understand that. I understand the rationale. * Next, the whole design doesn't feel right yet ... unfortunately we lack the time for relaxed iterations, so it should be considered as something. * I've added the mockup to Picasa if you want to discuss it with other people ... * Like the usual usability driven mockups, the visual design isn't available (missing colors icons, ...). Thus ... I got a design proposal that implements your Report a Problem box, I think (see attached). What do you think ? I think it will work well ... I had a few concerns whether people understand the sequence of the steps (at the moment, it rather looks like the tabs in recent software or on websites), but for a first iteration it's great. The only things I'd like to mention are that we usually don't use drop shadows and that we try to use lots of white - so the header may be a bit too dominant. For the visual design, we currently have the following resources: [... already added to the wiki page by your side ...] Maybe this helps to get an idea how the final design could look like. It makes things a lot clearer for me, indeed. The only thing I'll be missing is someone to slice the images from the mockup, so that I can work the CSS/HTML integration. I have limited skills with regard to producing images for background, buttons etc. and the web designer won't do it. I hope somebody can jump in - as I mentioned before, joining tomorrow (maybe even the
Re: [libreoffice-design] Future libreoffice.org web page: design request
Michael Meeks has a proposal regarding this aspect ( in http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20110906/9cc0ddfe/attachment-0001.odt ). If I had the required graphical elements, I could integrate them into the page. Do you know where I could find an image/icon for each components listed at https://bugassistant.libreoffice.org/query.cgi?format=advancedproduct=LibreOffice ? Just tell me the rough size (available: 256,128,48,32,16 px) of the graphics you need ... I'll export them for you. Here is the page where we've listed the LibO specific icons: http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design Mmh, the components list doesn't match exactly the components we use in LibO. So either: * we list only the main components (Writer, Calc, ...) * we show the main components prominently and provide a further list (e.g. UI, Linguistic component) -- my current favorite * we borrow some icons from the LibO UI And, there might be a need to hide some of them, e.g. WWW - but I'm not sure at the moment. Hi, I downloaded http://wiki.documentfoundation.org/cgi_img_auth.php/d/d4/LibreOffice_Initial_Icons-pre_final.svg linked from http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design and converted to PNG the 48x48 icons when available and added a placeholder for the missing ones ( BASIC, contrib, Linguistic component, Localization and UI). I added a display of these icons to the bug assistant ( no behavior attached, just for show ) at https://freedesktop.dachary.org/libreoffice/bug/bug.html as can be seen in the attached screenshot. However, I would like to emphasize that without a mockup I don't know what size the actual icons should be. The icons used and their size is up to the web designer and I will need to be given a mockup for the CSS / HTML integration. Maybe I can try to talk to directly to a web designer ? I confess that I can't really figure out who are the the active web designers from the mailing list ;-) Cheers -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] Future libreoffice.org web page: design request
That's absolutely great - and highly appreciated. But before we start, I'd like to know whether you are aware of two activities in the past that tried to address this issue. First, there has been a discussion on the developers list some months ago. Second, there has been an active discussion on the German mailing list some weeks ago (but I don't know the final outcome). Hi, I would like to emphasize that I'm a developer with little insight with regard to useability. It's a handicap shared by many developers and I came to acknowledge it over the years. My questions are related to the fact, that I already provided lots of detailed usability feedback within these threads - I assume that would be helpful for your work as well. For example: http://lists.freedesktop.org/archives/libreoffice/2011-March/009440.html Your mail was my first inspiration when I picked up where Daniel Neel left, back in february ( http://lists.freedesktop.org/archives/libreoffice/2011-February/008101.html ). I'm now trying to mix your vision with the one provided by Rainer Bielefeld and Michael Meeks ( which are listed with yours at http://wiki.documentfoundation.org/Bug_Submission_Assistant#Specifications ). It would greatly help if I had a bullet list of what should be implemented ( a proper specification is probably overkill, but details would be appreciated ). If there is a consensus on the priorities, it would help my technical work a great deal. I understand, however, that such research takes time and that you are all very busy. This is the reason why I went for a minimal implementation with what I believed to be the parts everyone agrees on. There are currently several things that make me ask who are the target users for this bug report form? And what is the reason for having such a form - improve the quality of bug reports, make it quicker to report them, make it easier for less experienced users, make it more visible to users that we care about such issues? My focus is to make it easier for someone who reports a bug for the second time and to improve the quality of the bug report by making sure the essential fields are filled in. The first time someone reports a bug, (s)he will need to register a bugzilla account which is difficult and there is no way around it. If we consider normal users, then e.g. the component selection is still very difficult to understand. Michael Meeks has a proposal regarding this aspect ( in http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20110906/9cc0ddfe/attachment-0001.odt ). If I had the required graphical elements, I could integrate them into the page. Do you know where I could find an image/icon for each components listed at https://bugassistant.libreoffice.org/query.cgi?format=advancedproduct=LibreOffice ? Or, asking them to create a bugzilla account (within this complex system) may reduce the need for a simple bug report assistant - those people who survive creating an bugzilla account are pre-filtered, so that a normal bug report form will work for them too (at least the hide advanced fields version). I agree that creating a bugzilla account is a major problem. I think nobody disputes this. I assumed the bug assistant was useful anyway because it was listed as a task. If it turns out to be redundant, I would appreciate to know as soon as possible ;-) I will keep going anyway, but I must confess that I'm worried now. Cheers -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
Re: [libreoffice-design] Future libreoffice.org web page: design request
Hi Loic, thanks for your answer - it already clarifies lots of my questions ... Am Freitag, den 09.09.2011, 09:44 +0200 schrieb Loic Dachary: [...] I would like to emphasize that I'm a developer with little insight with regard to useability. It's a handicap shared by many developers and I came to acknowledge it over the years. Then I emphasize that I lack the skills for developing the software ... that should be a basis for a very good partnership :-) [...] Your mail was my first inspiration when I picked up where Daniel Neel left, back in february ( http://lists.freedesktop.org/archives/libreoffice/2011-February/008101.html ). I'm now trying to mix your vision with the one provided by Rainer Bielefeld and Michael Meeks ( which are listed with yours at http://wiki.documentfoundation.org/Bug_Submission_Assistant#Specifications ). Thank you very much for the link ... today I was able to spend some time reading your page (very good overview, btw) and the document by Michael. I think I've got the main idea for this activity (please correct me if I'm wrong): It is less about simplifying reporting bugs for everyone, but it is about ... * to improve the quality of the initially provided information in the bug by providing guidance and automating e.g. LibO version identification. * some decoupling from the Freedesktop issue tracker which has also to suit the needs for many other projects * easing the way to report bugs in general (people should not search for a bug tracker) I'd say this addresses more experienced people - the minority of our user base (referring to the whole user base, not the community we know). Since we offer that feature for all people in LibO, some of them will get worried ... so there is a need to offer them alternatives (get help, provide feedback). That's something I've tried to summarize here: https://bugs.freedesktop.org/show_bug.cgi?id=35855#c6 Furthermore, it would allow us to get all kind of feedback by users, e.g. the surveys Bjoern analyses at the moment (see [1]). What do you think? @ Rainer: I should have been aware of this activity, but I've missed your comment in issue 35855 - I was not on CC, grrr. It would greatly help if I had a bullet list of what should be implemented ( a proper specification is probably overkill, but details would be appreciated ). If there is a consensus on the priorities, it would help my technical work a great deal. I understand, however, that such research takes time and that you are all very busy. This is the reason why I went for a minimal implementation with what I believed to be the parts everyone agrees on. Concerning the latter: great approach! In general, I'm happy to help, since this topic has been discussed so often in the past (I remember a heated discussion at the OOoCon 2010). But it will need two or three days to come up with anything from my side ... I hope that's acceptable. Or, maybe somebody from the Design team can jump in as well? Some things I'm currently unsure about is the terminology we use ... if we try to guide any type of users, then some technical terms should be avoided (for LibO / the initial website). I propose to use problem instead of bug/issue. [...] My focus is to make it easier for someone who reports a bug for the second time and to improve the quality of the bug report by making sure the essential fields are filled in. The first time someone reports a bug, (s)he will need to register a bugzilla account which is difficult and there is no way around it. Okay - that's very important for me, being aware of that. Thanks. If we consider normal users, then e.g. the component selection is still very difficult to understand. Michael Meeks has a proposal regarding this aspect ( in http://lists.freedesktop.org/archives/libreoffice-qa/attachments/20110906/9cc0ddfe/attachment-0001.odt ). If I had the required graphical elements, I could integrate them into the page. Do you know where I could find an image/icon for each components listed at https://bugassistant.libreoffice.org/query.cgi?format=advancedproduct=LibreOffice ? Just tell me the rough size (available: 256,128,48,32,16 px) of the graphics you need ... I'll export them for you. Here is the page where we've listed the LibO specific icons: http://wiki.documentfoundation.org/Design/LibreOffice_Initial_Icons#Present_State_of_the_Icon_Design Mmh, the components list doesn't match exactly the components we use in LibO. So either: * we list only the main components (Writer, Calc, ...) * we show the main components prominently and provide a further list (e.g. UI, Linguistic component) -- my current favorite * we borrow some icons from the LibO UI And, there might be a need to hide some of them, e.g. WWW - but I'm not sure at the moment. [...] If it turns out to be redundant, I would appreciate to know as soon as possible ;-) I will keep
[libreoffice-design] Future libreoffice.org web page: design request
Hi, I've been working on a web application to make it easier for libreoffice users to report bugs. Screenshots can be seen here: http://wiki.documentfoundation.org/Bug_Submission_Assistant_-_ToDo#Web_design As you can see, they are not nice looking and in great need for a skilled web designer. I am new to libreoffice and I apologize in advance if I've done something wrong. My understanding (after reading Christopher Noack advice to /Anant Verma at /http://listarchives.libreoffice.org/global/design/msg02916.html) is that http://wiki.documentfoundation.org/Design/Work_Items#Work_Items is the place where design related tasks are being proposed. I went ahead and created a new entry to advertise the need for mockups for the Bug submission assistant. This is currently the first entry in the table because I could not figure out if they are sorted chronologically or not. I hope that I did not do any mistake and I would very much appreciate any advice you could provide to improve the proposed work. In the meantime I will keep developing the web application. I am excited at the prospect of working on a nice looking bug report form :-) Thank you in advance for your help -- Unsubscribe instructions: E-mail to design+h...@global.libreoffice.org Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette List archive: http://listarchives.libreoffice.org/global/design/ All messages sent to this list will be publicly archived and cannot be deleted
