New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update design of code numbered #12

Closed
yaili opened this Issue Mar 17, 2017 · 14 comments

Comments

Projects
None yet
7 participants
@yaili
Contributor

yaili commented Mar 17, 2017

Designs for vanilla-framework issue 856

The purpose of adding some kind of visual division between line numbers and actual code is to make it more clear these are two different things, similar to what some code editors do.

There are 5 options here:

v1: Current code block version
1-code block proposal current

v2: More space between line numbers and code
2-code block proposal nothing

v3: Vertical divider between line numbers and code, with white background
3-code block proposal divider

v4: Background (cdcdcd) behind numbers (666666) - this was the initial suggestion, it's not accessible - could be accessible if the numbers are the same colour as text (111111)
4-code block proposal background

v5: Background (cdcdcd) behind numbers (ffffff) - same comments as 4
5-code block proposal background reverse

@yaili

This comment has been minimized.

Show comment
Hide comment
@yaili

yaili Mar 17, 2017

Contributor

@spencerbygraves @kwm14 @joanasa89 @jamiedawsonyoung @alexubuntu would love your comments on this.

Contributor

yaili commented Mar 17, 2017

@spencerbygraves @kwm14 @joanasa89 @jamiedawsonyoung @alexubuntu would love your comments on this.

@joanasa89

This comment has been minimized.

Show comment
Hide comment
@joanasa89

joanasa89 Mar 17, 2017

I think v3 works better (v4& v5 don't look accessible).

I think v3 works better (v4& v5 don't look accessible).

@kwm14

This comment has been minimized.

Show comment
Hide comment
@kwm14

kwm14 Mar 17, 2017

Contributor

+1 v3 too

  • good space between line numbers and code
  • vertical divider works well in splitting content
  • neutral colour scheme has better contrast, more legible
Contributor

kwm14 commented Mar 17, 2017

+1 v3 too

  • good space between line numbers and code
  • vertical divider works well in splitting content
  • neutral colour scheme has better contrast, more legible
@spencerbygraves

This comment has been minimized.

Show comment
Hide comment
@spencerbygraves

spencerbygraves Mar 17, 2017

Contributor

Happy with v3. I think the border should be #CDCDCD. We seem to have both versions here - https://docs.vanillaframework.io/en/patterns/code-numbered

Contributor

spencerbygraves commented Mar 17, 2017

Happy with v3. I think the border should be #CDCDCD. We seem to have both versions here - https://docs.vanillaframework.io/en/patterns/code-numbered

@jamiedawsonyoung

This comment has been minimized.

Show comment
Hide comment
@jamiedawsonyoung

jamiedawsonyoung Mar 17, 2017

V2 or V3 for me. 👍

Only thing about V3 is the amount of bits (white block, grey divider, grey background, text colours different) to it and whether that's too much? All the code editors I have don't put a divider between the number and the code (I've only got 3 on my machine mind) Also I wonder if the emphasis is more on the code numbers than the text when the number column is white? Does it work reversed?

Can we show a row highlight state for these or is that getting too complicated?

V2 or V3 for me. 👍

Only thing about V3 is the amount of bits (white block, grey divider, grey background, text colours different) to it and whether that's too much? All the code editors I have don't put a divider between the number and the code (I've only got 3 on my machine mind) Also I wonder if the emphasis is more on the code numbers than the text when the number column is white? Does it work reversed?

Can we show a row highlight state for these or is that getting too complicated?

@yaili

This comment has been minimized.

Show comment
Hide comment
@yaili

yaili Mar 17, 2017

Contributor

Good points, let me see if I can address them all:

  • @spencerbygraves the outer border was changed from cdcdcd from feedback from docs team as there was not enough contrast between the border and the background to differentiate from code blocks. The initial proposal was to revert to dark background but we didn't want to do that.
  • @jamiedawsonyoung I see what you mean… if we make the numbers light grey background and code white background, it won't be consistent with the normal code block which has light grey background
  • It doesn't seem that more code editors have a different background colour for line numbers than not, but personally I do think they bring a sense of knowledge/documentation/order to a large code block

I have made a couple more examples based on the feedback. Let me know your thoughts! :)

v6: Based on @jamiedawsonyoung's comment on emphasising the line numbers less

6-code block proposal divider reverse

v7: Variation on v6, without the divider line

7-code block proposal light background

Contributor

yaili commented Mar 17, 2017

Good points, let me see if I can address them all:

  • @spencerbygraves the outer border was changed from cdcdcd from feedback from docs team as there was not enough contrast between the border and the background to differentiate from code blocks. The initial proposal was to revert to dark background but we didn't want to do that.
  • @jamiedawsonyoung I see what you mean… if we make the numbers light grey background and code white background, it won't be consistent with the normal code block which has light grey background
  • It doesn't seem that more code editors have a different background colour for line numbers than not, but personally I do think they bring a sense of knowledge/documentation/order to a large code block

I have made a couple more examples based on the feedback. Let me know your thoughts! :)

v6: Based on @jamiedawsonyoung's comment on emphasising the line numbers less

6-code block proposal divider reverse

v7: Variation on v6, without the divider line

7-code block proposal light background

@jamiedawsonyoung

This comment has been minimized.

Show comment
Hide comment

V7 :-) Lovely

@spencerbygraves

This comment has been minimized.

Show comment
Hide comment
@spencerbygraves

spencerbygraves Mar 17, 2017

Contributor

I don't think we should change the background colour yet again.

I still favour v3 with the correct border colour :)

Contributor

spencerbygraves commented Mar 17, 2017

I don't think we should change the background colour yet again.

I still favour v3 with the correct border colour :)

@anthonydillon

This comment has been minimized.

Show comment
Hide comment
@anthonydillon

anthonydillon Mar 17, 2017

Contributor
Contributor

anthonydillon commented Mar 17, 2017

@yaili

This comment has been minimized.

Show comment
Hide comment
@yaili

yaili Mar 21, 2017

Contributor

Based on feedback from design review, here is the latest version:

v8: variation of v3 with all borders the same colour

8-code block proposal divider dark

Contributor

yaili commented Mar 21, 2017

Based on feedback from design review, here is the latest version:

v8: variation of v3 with all borders the same colour

8-code block proposal divider dark

@yaili

This comment has been minimized.

Show comment
Hide comment
@yaili

yaili Mar 21, 2017

Contributor

@marcush could you have a look when you've got a moment? thanks 👍

Contributor

yaili commented Mar 21, 2017

@marcush could you have a look when you've got a moment? thanks 👍

@marcush

This comment has been minimized.

Show comment
Hide comment
@marcush

marcush Mar 23, 2017

I like v8 - variation of v3
Although I do like v5 as well

marcush commented Mar 23, 2017

I like v8 - variation of v3
Although I do like v5 as well

@yaili

This comment has been minimized.

Show comment
Hide comment
@yaili

yaili Mar 23, 2017

Contributor

@marcush thank you. In v4 and v5 the numbers aren't accessible though :(

Contributor

yaili commented Mar 23, 2017

@marcush thank you. In v4 and v5 the numbers aren't accessible though :(

@yaili

This comment has been minimized.

Show comment
Hide comment

@yaili yaili closed this Mar 24, 2017

@wafflebot wafflebot bot removed the Status: Review label Mar 24, 2017

barkinet added a commit to barkinet/vanilla-design that referenced this issue May 5, 2017

Create README.md
Jump to contentHomeTopics
Design
Development
Notes
Research
User Experience
ArchivesTeamSearch:Searchubuntu design blog
Designing in the open
 Anthony's photo Anthony Dillon Posted on 25th April 2017Filed under: Design Development User Experience
Share this article:
Share on Twitter
Share via Email
Share on Facebook
Share on Google+
Over the past year, a change has emerged in the design team here at Canonical: we’ve started designing our websites and apps in public GitHub repositories, and therefore sharing the entire design process with the world.

One of the main things we wanted to improve was the design sign off process whilst increasing visibility for developers of which design was the final one among numerous iterations and inconsistent labelling of files and folders.

Here is the process we developed and have been using on multiple projects.

The process
Design work items are initiated by creating a GitHub issue on the design repository relating to the project. Each project consists of two repositories: one for the code base and another for designs. The work item issue contains a short descriptive title followed by a detailed description of the problem or feature.


Code block styling from ubuntudesign#12

Once the designer has created one or more designs to present, they upload them to the issue with a description. Each image is titled with a version number to help reference in subsequent comments.

Whenever the designer updates the GitHub issue everyone who is watching the project receives an email update. It is important for anyone interested or with a stake in the project to watch the design repositories that are relevant to them.

The designer can continue to iterate on the task safe in the knowledge that everyone can see the designs in their own time and provide feedback if needed. The feedback that comes in at this stage is welcomed, as early feedback is usually better than late.

As iterations of the design are created, the designer simply adds them to the existing issue with a comment of the changes they made and any feedback from any review meetings.


Table with actions design from MAAS project

When the design is finalised a pull request is created and linked to the GitHub issue, by adding “Fixes #111” (where #111 is the number of the original issue) to the pull request description. The pull request contains the final design in a folder structure that makes sense for the project.

Just like with code, the pull request is then approved by another designer or the person with the final say. This may seem like an extra step, but it allows another person to look through the issue and make sure the design completes the design goal. On smaller teams, this pull request can be approved by a stakeholder or developer.

Once the pull request is approved it can be merged. This will close and archive the issue and add the final design to the code section of the design repository.

That’s it!

Benefits
If all designers and developers of a project subscribe to the design repository, they will be included in the iterative design process with plenty of email reminders. This increases the visibility of designs in progress to stakeholders, developers and other designers, allowing for wider feedback at all stages of the design process.

Another benefit of this process is having a full history of decisions made and the evolution of a design all contained within a single page.

If your project is open source, this process makes your designs available to your community or anyone that is interested in the product automatically. This means that anyone who wants to contribute to the project has access to all the information and assets as the team members.

The code section of the design repository becomes the home for all signed off designs. If a developer is ever unsure as to what something should look like, they can reference the relevant folder in the design repository and be confident that it is the latest design.

Canonical is largely a company of remote workers and sometimes conversations are not documented, this means some people will be aware of the decisions and conversations. This design process has helped with the issue, as designs and discussions are all in a single place, with nicely laid out emails for all changes that anyone may be interested.

Conclusion
This process has helped our team improve velocity and transparency. Is this something you’ve considered or have done in your own projects? Let us know in the comments, we’d love to hear of any way we can improve the process.

Add your comment

Your name (required) 
Your email (required) 
Your website 
Your comment (required) 
Submit Comment
Join us!

Passionate about good design and creating delightful experiences? We’re looking for people who love to learn and share their knowledge and ideas.

See all the design jobs on canonical.com

Follow
@ubuntudesigners on Twitter
Make Ubuntu
Brand guidelines
© 2017 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.Report a bug on this siteRSS feedhttp://canonical.comBack to top
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment