profile
viewpoint

AlicjaSuska/carful-landing-page 1

Landing page for carpooling mobile app named Carful

AlicjaSuska/github-slideshow 0

A robot powered training repository :robot:

issue commentsourcegraph/sourcegraph

Extensions discoverability

RFC is ready for the final review.

@tjkandala will be handling the implementation of the changes on the extensions registry page 🎉

christinaforney

comment created time in 11 hours

issue commentsourcegraph/sourcegraph

Sign in page has ugly navbar

I think it would make sense to incorporate in it the Information Architecture project. I think I can take some time next week to prepare the designs. @rrhyne why do you think it should be a separate project? Are there any other UX changes that need to happen outside of the visual adjustments?

slimsag

comment created time in 4 days

issue commentsourcegraph/sourcegraph

Extensions discoverability

I've created an RFC for the project to gather all the information in one place. @christinaforney @rrhyne that would be great if you can review it, then I'll make changes and start the usability testing! 🎉

Current state:

Ready to review: All details regarding the discoverability, extensions registry change and adding more information about publishing extensions.

Still WIP: 'using extensions' - management of the bar and command line

christinaforney

comment created time in 8 days

issue openedsourcegraph/sourcegraph

Word-count extension doesn't work and turns other extensions off

  • Sourcegraph version: sourcegraph.com<!-- the version of Sourcegraph or "Sourcegraph.com" -->
  • Platform information: Chrome 84.0.4147.89 on MacOS Catalina 10.15.5 (19F101)<!-- OS version, cloud provider, web browser version, Docker version, etc., depending on the issue -->

Steps to reproduce:

See the recording

  1. Turn on extensions that would be visible in the toolbar (codecov, git-extras, vscode-extras)
  2. Go to the file (I used this one) Extensions work, icons are displayed in the bar. The command palette can be opened.
  3. Turn on the word-count extension
  4. Come back to the file (refresh) Extensions do not work, icons disappear from the bar. The command palette doesn't open. Word count does not work.
  5. Turn off the word-count extension
  6. Come back to the file (refresh) Extension work again, icons are back in the bar. The command palette can be opened.

Expected behavior:

  • Word-count extension displays the number of words in the file
  • Other extensions work and their icons are displayed in the bar
  • It is possible to open the command palette

Actual behavior:

When word-count extension is on:

  • word count is not displayed, information given: 'open a file to see the word count'
  • other extensions stop working, their icons disappear from the bar
  • it is impossible to open the command palette.

created time in 9 days

issue commentsourcegraph/sourcegraph

Extensions discoverability

Connected to this issue: 'Add tags to Git-extras extension' #12485

christinaforney

comment created time in 9 days

issue openedsourcegraph/sourcegraph

Add tags to Git-extras extension

Git-extras extension has no tags assigned. It comes up when searching for keywords like 'GitHub' or 'GitLab' but other related terms are not searchable. In particular, it is impossible to search for 'blame':

Screenshot 2020-07-26 at 14 38 32

Proposition: Add the following tags to improve search experience:

  • 'blame'
  • 'GitHub'
  • 'GitLab'
  • 'code host'
  • 'author'

Tags are up for discussion - I would love to see your feedback and other ideas.

This improvement came up when working on the 'Extensions discoverability' project #11872

Git-extras currently (no tags): Screenshot 2020-07-26 at 14 42 52

@rrhyne - regarding our discussion from last week @christinaforney @felixfbecker

created time in 9 days

push eventsourcegraph/about

AlicjaSuska

commit sha 1e1cf4fe72a93ddd6b23425f9ea118437776848f

Typo fixed

view details

push time in 9 days

PR opened sourcegraph/about

Reviewers
Add items to the Product onboarding handbook

Based on my recent onboarding experience, I've added a couple of activities that helped me and could be useful for all new Product Team members 🎉

+4 -0

0 comment

1 changed file

pr created time in 9 days

create barnchsourcegraph/about

branch : Add-items-to-the-Product-onboarding

created branch time in 9 days

issue commentsourcegraph/sourcegraph

'About Sourcegraph' and 'Help' pages should be opened in the separate tab

Friendly reminder @rrhyne @felixfbecker

AlicjaSuska

comment created time in 12 days

pull request commentsourcegraph/about

Design handoff process

@christinaforney I've merged my PR regarding headers and design files handling yesterday. That's probably why they overlap. In this one only part about the hand-off is new :)

rrhyne

comment created time in 12 days

Pull request review commentsourcegraph/about

Design handoff process

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Design to engineering handoff**+    - Design preperation+        - Ensure colors utilize the named color styles vs. the color palette where possible 

I would add some examples: 'Ensure colors utilize the named color styles (ex. web-styles/body-color/light) vs. the color palette (ex. grey-7) where possible

rrhyne

comment created time in 12 days

Pull request review commentsourcegraph/about

Design handoff process

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Design to engineering handoff**+    - Design preperation+        - Ensure colors utilize the named color styles vs. the color palette where possible +            - This adds our color style variable name to the code palette +        - Redline any colors, styles, margins and paddings unique to the designs (not provided by a component)+        - If introducing new colors, type, or other design elements, ask for review by an engineer focused on styles and React components+        - Ensure any illustrations work in both light and dark mode +        - TODO: Determine method of illustration/image exports

Let's start this discussion. @felixfbecker would you like to share your thoughts about what would be the preferred illustrations export? :)

rrhyne

comment created time in 12 days

Pull request review commentsourcegraph/about

Design handoff process

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Design to engineering handoff**+    - Design preperation+        - Ensure colors utilize the named color styles vs. the color palette where possible +            - This adds our color style variable name to the code palette +        - Redline any colors, styles, margins and paddings unique to the designs (not provided by a component)+        - If introducing new colors, type, or other design elements, ask for review by an engineer focused on styles and React components

TODO: design-engineering review process (probably using Chromatic)

rrhyne

comment created time in 12 days

Pull request review commentsourcegraph/about

Design handoff process

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Design to engineering handoff**+    - Design preperation+        - Ensure colors utilize the named color styles vs. the color palette where possible +            - This adds our color style variable name to the code palette +        - Redline any colors, styles, margins and paddings unique to the designs (not provided by a component)

Let's add: '...use em values (not px)'

rrhyne

comment created time in 12 days

Pull request review commentsourcegraph/about

Design handoff process

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Design to engineering handoff**+    - Design preperation+        - Ensure colors utilize the named color styles vs. the color palette where possible +            - This adds our color style variable name to the code palette 

I'm not sure what you mean here by 'this'

rrhyne

comment created time in 12 days

push eventsourcegraph/about

AlicjaSuska

commit sha 840ea7b5862869e9d16580d9561c7fda75c7d81a

Add Working with design files + heading update (#1187) * Add Working with design files + heading update I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools. In addition, I've changed slightly the formatting of the 'Process segments' section - using bold text for the main steps in the process increases the readability of this document. Please, share your feedback regarding both the content and the form :) Thank you! * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com> * Add Pages to 'File structure' according Changes according to Rob's suggestion. @rrhyne please review. Thank you! Co-authored-by: Rob Rhyne <rob@sourcegraph.com> Co-authored-by: Christina Forney <christina@sourcegraph.com>

view details

push time in 13 days

delete branch sourcegraph/about

delete branch : Add-Working-with-design-files,-update-Design-Process-headers

delete time in 13 days

PR merged sourcegraph/about

Add Working with design files + heading update

I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools.

In addition, I've changed slightly the formatting of the 'Process segments' section - using bold text for the main steps in the process increases the readability of this document.

Please, share your feedback regarding both the content and the form :) Thank you!

+42 -8

0 comment

1 changed file

AlicjaSuska

pr closed time in 13 days

issue commentsourcegraph/sourcegraph

Design templates for common page types

@lguychard here is the plan for breadcrumbs and headers implementation that I've mentioned during the last web sync. Just making sure you had a chance to review it :)

christinaforney

comment created time in 14 days

issue commentsourcegraph/sourcegraph

Extensions discoverability

Notes from the kick-off meeting with @christinaforney. This is a summary of the most important problems for this project with possible solutions.

  1. Discoverability - extensions should stand out more on the platform.
  • Add the 'Extensions' tab to the main navigation.
  1. Extensions registry is overwhelming
  • Group extensions in categories
  • Add categories as filters
  • Bring enabled/disabled filters to the front
  • Hide extensions that are WIP
  • Make sure that language extensions are on (for code intelligence)
  1. Communicate the value
  • add a description that explains what extensions are and why they are useful.
  1. Encourage users and companies to create their own extensions
  • add a link to the documentation
  • make this possibility stand out more on the website
  1. Explore the idea of 'approved' extensions
  • help for users to understand which extensions are ready to use and recommended by Sourcegraph
  • how would the approval process look like?
  • beta and WIP extensions - distinction, which should be on the main page, etc.
  1. Extensions behaviour and bar management
  • extensions shouldn't disappear from the toolbar to not confuse the users. They can be inactive.
  • how to manage extensions bar
  • any other suggestions that would improve the experience
  1. Command palette
  • is placement correct?
  • an empty state could 'advertise' the feature
christinaforney

comment created time in 14 days

issue commentsourcegraph/sourcegraph

Map the current information architecture

The information architecture doc is ready for review 🎉

List of the most important changes:

  1. Navigation:
  • new order of the top navbar
  • remove Explore page
  • add Extensions for authorized users
  • possibly hide command palette or change its icon
  • add 'register button for un-auth users
  1. Explore page - delete the page and possibly move some of its contents to the Home page
  2. Settings - design and labeling improvements
  3. Site admin - design and labeling improvements
  4. Organization - design and labeling improvements

This document also presents work on the navigation bar structure.

Please, see also the sitemap for better visual overview.

URL structure I agree with @rrhyne proposition to add repositories part to the URL structure so it is more consistent with our page structure and breadcrumbs that will be presented to the user after we implement changes from the issue 11774.

Example: https://sourcegraph.com/repositories/github.com/rrhyne/repository-name

@rrhyne @christinaforney @felixfbecker

christinaforney

comment created time in 18 days

PR opened sourcegraph/sourcegraph

Add Figma URL for UserNavItem

<!-- Reminder: Have you updated the changelog and relevant docs (user docs, architecture diagram, etc) ? -->

+35 -26

0 comment

1 changed file

pr created time in 18 days

create barnchsourcegraph/sourcegraph

branch : user-nav-item-figma

created branch time in 18 days

push eventsourcegraph/about

AlicjaSuska

commit sha fa33e4dc2ee2499834f69d70bf8bbd9228b2b13d

Add Pages to 'File structure' according Changes according to Rob's suggestion. @rrhyne please review. Thank you!

view details

push time in 19 days

push eventsourcegraph/about

AlicjaSuska

commit sha 768490cb1d870aefa7886a67a35e1258da3da5d7

Update handbook/product/design/design-process.md Co-authored-by: Christina Forney <christina@sourcegraph.com>

view details

push time in 19 days

Pull request review commentsourcegraph/about

Add Working with design files + heading update

 While asynchronous communication is a core attribute of remote work, key moments       - Schedule a meeting with engineers to discuss the interaction   - Tools       - Figma-- Metrics collection:+- **Metrics collection**   - In the RFC process, the definition of success will include items which can be measured and evaluated   - Involve the business operations team in determining what metrics to track and how they are tracked   - Work with engineers to add the required eventLog tracking   - Tools       - Looker       - Google analytics-- Refinement+- **Refinement**   - Designers will review metrics and determine if their designs are meeting objectives set for them.   - If areas for improvement are found, tickets will be created to document the change required to improve the issue+  +## Working with design files+To provide consistency in design files handling, follow the rules listed below:++#### File location+All files should be created under the Sourcegraph organization in Figma. It is important to not work on Sourcegraph projects in the private files as designs should be accessible to all Team Members.++#### Naming convention+- All the files containing current project work must follow this naming structure:++RFC or GitHub issue number + RCF or GitHub issue title + stage (Draft, Open to review, Final review or Approved).++- Keep the stage updated as you progress with your work. ++#### Project Tools+Use [Project Tools](https://www.figma.com/file/8qNcDzOXLj1hcOM76WDPN9/Project-Tools?node-id=0%3A1) to provide more information about the project directly in the Figma file. It will help all the visitors connect files to the related RFC or GitHub issue and understand better all the details about the design.++- Project Card - displays basic information about project ex. reviewers, RFC and GitHub issue links, deadlines etc. It should be created for every file.++- Project Introduction - necessary when sharing your prototype with the Team. It should contain details about the target audience and project goals, to provide good context before starting the review.++- Final Page - placed at the end of the prototype. It shows additional notes on the solution, points out the most important pages in the prototype and describes what feedback the designer is looking for. It also instructs reviewers on how to leave comments.++#### File structure

That looks good @rrhyne. I think not all of those pages ill be required for every file. Maybe we can add a note 'Use only pages that are necessary for your file'. What do you think about it?

AlicjaSuska

comment created time in 19 days

Pull request review commentsourcegraph/about

Formatting and adding final review section

 While asynchronous communication is a core attribute of remote work, key moments  ## Process segments -- Ideation-  - This is generally represented by a kickoff meeting with interested parties. Kickoff meetings should generally include representatives of the following parties:-      - The product manager-      - Developers working on the project-      - Designers-      - Sales, ops and customer engineering staff who have insight into how this affects users-      - Customers if available-      - Stakeholders as required-  - Tools-      - We are experimenting with [miro.com](https://miro.com/) as an ideation tool-      - Figma.com can be used to generate mood boards+### Ideation++- This is generally represented by a kickoff meeting with interested parties. Kickoff meetings should generally include representatives of the following parties:+    - The product manager+    - Developers working on the project+    - Designers+    - Sales, ops and customer engineering staff who have insight into how this affects users+    - Customers if available+    - Stakeholders as required+- Tools+    - We are experimenting with [miro.com](https://miro.com/) as an ideation tool+    - Figma.com can be used to generate mood boards - Research-  - Interview internal users-      - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented-  - Interview external users-      - Where the project requires and time permits, conduct research with these users to inform your designs-  - Customer requests and support tickets-      - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)-  - Analogous designs-  - Competitive designs-  - Usability tests-    - When updating existing product features, first conduct usability tests to inform redesign decisions-  - Process-      - A GitHub issue should be created to track the work-      - Research is conducted according to requirements-      - Findings publishing and review-        - Findings should be detailed in a Google doc and announced in the corresponding team channel or #product on Slack-        - Findings should contain a clear summary, links to resources and supporting data-        - Conduct a synchronous review meeting with key stakeholders based on the size of project or importance of findings-      - Schedule and conduct a presentation meeting with stakeholders where necessary-  - Tools-      - Google Docs-      - Google Forms for polls-      - UserTesting.com-      - Maze.design-- Wireframes-  - Wireframes should utilize the Sourcegraph Figma component system-  - Wireframes should generally utilize realistic data and text for each element. In cases where many elements are required, ‘lorem epsum’ placeholder text will suffice if the initial or prominent elements are real data.-  - Process-      - A GitHub issue should be created to track the work-          - Label the issue with the design and/or ux label-          - TBD - how do we replicate pull request reviewers?-      - Wireframes are produced in Figma-      - Wireframes are announced in Slack and linked in the GitHub issue well before they are complete for review-      - Wireframes are hallway tested with internal users and product managers-      - Schedule and conduct a presentation meeting-      - Stakeholders will approve the GitHub issue indicating the designs are ready for the next phase-  - Checklist-      - Ensure designs meet Jacob Nielsen's [ten usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)+- Interview internal users+    - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented+- Interview external users+    - Where the project requires and time permits, conduct research with these users to inform your designs+- Customer requests and support tickets+    - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)+- Analogous designs+- Competitive designs+- Usability tests+  - When updating existing product features, first conduct usability tests to inform redesign decisions+- Process+    - A GitHub issue should be created to track the work+    - Research is conducted according to requirements+    - Findings publishing and review+      - Findings should be detailed in a Google doc and announced in the corresponding team channel or #product on Slack+      - Findings should contain a clear summary, links to resources and supporting data+      - Conduct a synchronous review meeting with key stakeholders based on the size of project or importance of findings+    - Schedule and conduct a presentation meeting with stakeholders where necessary+- Tools+    - Google Docs+    - Google Forms for polls+    - UserTesting.com+    - Maze.design++### Wireframes++- Wireframes should utilize the Sourcegraph Figma component system+- Wireframes should generally utilize realistic data and text for each element. In cases where many elements are required, ‘lorem epsum’ placeholder text will suffice if the initial or prominent elements are real data.+- Process+    - A GitHub issue should be created to track the work+        - Label the issue with the design and/or ux label+        - TBD - how do we replicate pull request reviewers?+    - Wireframes are produced in Figma+    - Wireframes are announced in Slack and linked in the GitHub issue well before they are complete for review+    - Wireframes are hallway tested with internal users and product managers+    - Schedule and conduct a presentation meeting+    - Stakeholders will approve the GitHub issue indicating the designs are ready for the next phase+- Checklist+    - Ensure designs meet Jacob Nielsen's [ten usability heuristics](https://www.nngroup.com/articles/ten-usability-heuristics/)+    - Has the change’s effect on the CLI been considered?+        - Does the language in the UI map to the language in the CLI?+    - Enterprise / Cloud+    - Signed in vs. anonymous user+    - User permissions+    - Interactive mode / plain text mode+    - TBD - add a standard UX checklist+- Tools+    - Figma++### Testing++- Process+    - A GitHub issue should be created to track the work+    - Testing is conducted according to requirements+    - Publish testing results summary to google drive+    - Announce results in slack+    - Create a GitHub issue to address items in the test results+- Tools+    - Maze.design+    - UserTesting.org++### Visual design++- Visual design should utilize the Sourcegraph’s Figma based component system+- Dark compositions will be created for each major design+- If new components are required, components will be created in the file itself, not the component system+- Improvements to the Sourcegraph user experience should consider the following in every change:       - Has the change’s effect on the CLI been considered?-          - Does the language in the UI map to the language in the CLI?+      - Does the language in the UI map to the language in the CLI?+      - Does the documentation reflect the change?+      - Light mode / Dark mode       - Enterprise / Cloud       - Signed in vs. anonymous user       - User permissions       - Interactive mode / plain text mode-      - TBD - add a standard UX checklist-  - Tools-      - Figma-- Testing-  - Process-      - A GitHub issue should be created to track the work-      - Testing is conducted according to requirements-      - Publish testing results summary to google drive-      - Announce results in slack-      - Create a GitHub issue to address items in the test results-  - Tools-      - Maze.design-      - UserTesting.org-- Visual design-  - Visual design should utilize the Sourcegraph’s Figma based component system-  - Dark compositions will be created for each major design-  - If new components are required, components will be created in the file itself, not the component system-  - Improvements to the Sourcegraph user experience should consider the following in every change:-        - Has the change’s effect on the CLI been considered?-        - Does the language in the UI map to the language in the CLI?-        - Does the documentation reflect the change?-        - Light mode / Dark mode-        - Enterprise / Cloud-        - Signed in vs. anonymous user-        - User permissions-        - Interactive mode / plain text mode-  - Process-      - A GitHub issue should be created to track the work-      - Designs are produced in Figma-      - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review-      - Ensure designs meet the visual design checklist:-        - Ensure spacing is consistent and matches the 8pt grid system-        - Ensure text, colors and other sytles match existing styles, if possible. -          - Introduce new text styles only if really necessary.-          - If adding new styles, ensure that they meet the accessibility standards and add them to the design system -        - Review designs for accessability:-          - Color blind check-          - Contrast check should meet AA standard for small text-      - Schedule and conduct a design presentation meeting if the size of the project requires-      - Receive signoff from stakeholders-      - If components were created in the visual design process, when the designs are signed off on, those components will be moved to the Sourcegraph component system-      - Prepare redlines or an interaction delivery writeup for the engineers. Consider the following:-          - Margin and padding-          - Animation-          - Links and hover states-      - Describe expected behavior of layout for tablet and moble screensizes-        - Due to the low number of mobile and table visitors (< 3%) design comps for these sizes are generally not required -      - Schedule a meeting with engineers to discuss the interaction-  - Tools-      - Figma-- Metrics collection:-  - In the RFC process, the definition of success will include items which can be measured and evaluated-  - Involve the business operations team in determining what metrics to track and how they are tracked-  - Work with engineers to add the required eventLog tracking-  - Tools-      - Looker-      - Google analytics-- Refinement-  - Designers will review metrics and determine if their designs are meeting objectives set for them.-  - If areas for improvement are found, tickets will be created to document the change required to improve the issue+- Process+    - A GitHub issue should be created to track the work+    - Designs are produced in Figma+    - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review+    - Ensure designs meet the visual design checklist:+      - Ensure spacing is consistent and matches the 8pt grid system+      - Ensure text, colors and other sytles match existing styles, if possible. +        - Introduce new text styles only if really necessary.+        - If adding new styles, ensure that they meet the accessibility standards and add them to the design system +      - Review designs for accessability:+        - Color blind check+        - Contrast check should meet AA standard for small text+    - Schedule and conduct a design presentation meeting if the size of the project requires+    - Receive signoff from stakeholders+    - If components were created in the visual design process, when the designs are signed off on, those components will be moved to the Sourcegraph component system+    - Prepare redlines or an interaction delivery writeup for the engineers. Consider the following:+        - Margin and padding+        - Animation+        - Links and hover states+    - Describe expected behavior of layout for tablet and moble screensizes+      - Due to the low number of mobile and table visitors (< 3%) design comps for these sizes are generally not required +    - Schedule a meeting with engineers to discuss the interaction+- Tools+    - Figma++### Metrics collection++- In the RFC process, the definition of success will include items which can be measured and evaluated+- Involve the business operations team in determining what metrics to track and how they are tracked+- Work with engineers to add the required eventLog tracking+- Tools+    - Looker+    - Google analytics++### Refinement++- Designers will review metrics and determine if their designs are meeting objectives set for them.+- If areas for improvement are found, tickets will be created to document the change required to improve the issue  +### Final review of implementation +- Test the feature for both themes, Light and Dark. Check for icon consistency across themes.

What icon do you have in mind here? @christinaforney

christinaforney

comment created time in 19 days

issue openedsourcegraph/sourcegraph

'About Sourcegraph' and 'Help' pages should be opened in the separate tab

Current state:

  • Authorized users: 'Help' and 'About Sourcegraph' links, accessible from the 'Profile' dropdown, opens in the new tab
  • Un-authorized users: 'Help' and 'About' links, accessible from the top navigation, opens in the same tab.

Proposed changes:

  • Open Help and About links in the separate tab for all users. We would avoid taking them out of the context of the app.
  • Add 'open in the new tab' icon in the dropdown menu visible for authorized users.

See in Figma

Menu-icon

created time in 19 days

issue commentsourcegraph/sourcegraph

Placeholder text colour contrast doesn't meet the accessibility standards

@felixfbecker @rrhyne can we agree on the following and move forward with those changes:

  • dark theme - Grey 6 (#878E95)
  • light theme - add new color #6B7385 (effectively the same as currently used grey #2b3750 with 70% opacity on the white background).

Please, share your feedback. Thank you!

AlicjaSuska

comment created time in 20 days

pull request commentsourcegraph/about

wip goals

Thank you for sharing those changes @sqs!

I've seen that the 'Structure and format' section is still in 'to do' so I hope my feedback will be helpful :)

As we are planning to have all short-, medium- and long-term goals, I think it would be useful to define sub-goals or steps to take for each goal. As for medium- and long-term goals we may not know all the steps from the beginning, I've come up with the following proposition:

Criteria for defining goals:

  • Short-term goal - all steps should be defined
  • Medium-term goal - define 3-4 steps that need to be taken first
  • Long-term goal - define 1-2 initial steps

For mid- and long-term goals, plans can change a lot. By adding the first steps at the beginning, we define the most immediate actions that should be taken. By leaving the possibility to add more steps as time goes by, we make continuous planning easier.

Please, let me know what do you think about this approach.

sqs

comment created time in 20 days

issue commentsourcegraph/sourcegraph

Map the current information architecture

Information architecture and propositions of improvements are being documented in this Doc. These are the main parts that I will be focusing on:

  • [ ] Structure of the pages

  • [ ] Navigation bar

  • [ ] URLs

All parts will be reviewed in the context of consistency between authorized and anonymous users.

christinaforney

comment created time in 22 days

PR opened sourcegraph/about

Reviewers
Add Plugins and Project Tools

Let's add Red Lines and Contrast Checker plugins to the onboarding process. They are very useful.

In addition, new designers should get familiar with the Project Tools document to be able to document their Figma files properly.

+5 -2

0 comment

1 changed file

pr created time in 23 days

PR opened sourcegraph/about

Reviewers
Add Working with design files + heading update

I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools.

In addition, I've changed slightly the formatting of the 'Process segments' section - using bold text for the main steps in the process increases the readability of this document.

Please, share your feedback regarding both the content and the form :) Thank you!

+32 -7

0 comment

1 changed file

pr created time in 23 days

push eventsourcegraph/about

AlicjaSuska

commit sha 67a40e8da06ee9908752b57f6f37ae283a95bed3

Reversing the previous commit I've committed my proposed changes to the master by mistake. This commit reverses those changes to the previous state.

view details

push time in 23 days

push eventsourcegraph/about

AlicjaSuska

commit sha 83b72b6a134dae4d388a08bc3d55e3f3868134b2

Add Working with design files + heading update I've added 'Working with design files' section that describes all the rules that we've agreed on recently when it comes to working with Figma files, naming conventions and Project Tools. In addition, I've changed slightly the formatting of the 'Process segments' section - using headers for the main steps in the process increases the readability of this document. Please, share your feedback regarding both the content and the form :) Thank you!

view details

push time in 23 days

issue commentsourcegraph/sourcegraph

Placeholder text colour contrast doesn't meet the accessibility standards

For the dark theme, we can use Grey 6 (#878E95). It is very similar to the color we're using now. Also, it passes the test.

For the light theme: Grey 6 doesn't meet the accessibility standards. Grey 7 is too dark - it looks like a regular text. Here is the comparison: Screenshot 2020-07-12 at 11 39 00

It looks like for the light theme, we need to introduce another color. If we decide to use 100% opacity, I would go with #6B7385 (effectively the same as currently used grey #2b3750 with 70% opacity on the white background).

@felixfbecker

AlicjaSuska

comment created time in 23 days

issue commentsourcegraph/sourcegraph

Design templates for common page types

@christinaforney what should be the next steps regarding this issue?

christinaforney

comment created time in 24 days

issue commentsourcegraph/sourcegraph

Use Chromatic to host our Storybook

Thank you for bringing this up Felix! It seems like a good addition to the workflow. In particular, I like the ability to have discussions exclusively about the components!

felixfbecker

comment created time in 24 days

issue commentsourcegraph/sourcegraph

Design templates for common page types

Great news! Designs are ready for the final review 🎉 Please, see this Figma link.

The scope of this issue turned out to be bigger than expected. Headers need to be changed on many additional pages (not only Insights, Extensions and Campaigns which were planned at the beginning).

In addition, breadcrumbs needs to be created and implemented for all the headers and search pages. Also, existing toggle elements need to be updated, bigger versions of them implemented, and used in the Extension Details Page.

Here is my proposition of the order of implementation (all steps should be taken for both light and dark theme):

Step 1: Breadcrumbs component

  • [ ] Simple 'web-oriented' breadcrumbs

  • [ ] More complex 'search-oriented' breadcrumbs

Step 2: Header component

  • [ ] Create two types of headers:

  • Smaller (144px h) used in the majority of pages

  • Bigger (176 px h) used in Extension details, Profile and Organisation pages

Step 3: Toggle buttons

  • [ ] Update style of small toggle buttons (used on Extensions List page)

  • [ ] Create big toggle buttons (used on Extension Details page)

Step 4: Implement breadcrumbs and headers

  • [ ] Implement new breadcrumbs for the Search pages

  • [ ] Implement new headers for the following pages:

  • Insights

  • Campaigns

  • Campaign details

  • Extensions list

  • Extension details (with new big toggle button)

  • Explore

  • Query builder

  • Code statistics

  • Settings

  • Organization

Step 5: Analytics

  • [ ] Breadcrumbs - create events to track if and how people are using them

  • [ ] Big toggle button on the Extension Details Page - check if making the button more noticeable had a positive impact on the number of people turning on the extensions when visiting the page

@ebrodymoore following up on our discussion here. That would be great if you can help me set this up :)

christinaforney

comment created time in a month

issue commentsourcegraph/sourcegraph

Placeholder text colour contrast doesn't meet the accessibility standards

Hi @felixfbecker, thank you for the feedback. When it comes to choosing from the existing palettes:

  • grey-ish palette becomes too blue to use it directly for lighter tones. The text starts looking like a link, not like a placeholder
  • grey from the basic palette - grey 5 doesn't meet the standards, grey 7 is too dark (it looks like a regular text).

We can:

  • increase the opacity of the currently used color from 50% to 70% to meet the accessibility standards. or
  • introduce the new color to the palette #6B7385 for placeholder texts.

In general, it is a bigger discussion about if we would like to use the opacity for at all. It limits the number of colors we need to define but, in reality, we create even more inconsistencies and cases as the element's color depends on the background. we've discussed it with @felixfbecker briefly. I think we've agreed that no opacity would be a better solution. @rrhyne what is your take on that?

AlicjaSuska

comment created time in a month

issue openedsourcegraph/sourcegraph

Placeholder text colour contrast doesn't meet the accessibility standards

Currently used placeholder text color (#2B3750 50% opacity) doesn't meet the accessibility standards. My proposition is to change it to #6C7584 100% opacity. This is the closest color to the currently used one, that meets the standards.

Placeholder text is used in many places:

  • main search bar ghost text 'Search code'
  • query builder text fields
  • site admin - user stats search bar
  • text fields in profile settings etc.

See the document that showcases current color and new proposition with contrast ratio test results.

created time in a month

Pull request review commentsourcegraph/about

Update checklists

 While asynchronous communication is a core attribute of remote work, key moments         - Interactive mode / plain text mode   - Process       - A GitHub issue should be created to track the work-      - Wireframes are produced in Figma-      - Wireframes will be announced in Slack and linked in the GitHub issue well before they are complete for review-      - Schedule and conduct a research presentation meeting+      - Designs are produced in Figma+      - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review+      - Ensure designs meet the visual design checklist:+        - Ensure spacing is consistent and matches the 8pt grid system+        - Ensure colors match existing styles+          - If new styles are introduced, label them clearly+        - Review designs for accessability:+          - Color blind check+          - Contrast check

I would specify here: 'Aim to meet at least AA standard for small text'

rrhyne

comment created time in a month

Pull request review commentsourcegraph/about

Update checklists

 While asynchronous communication is a core attribute of remote work, key moments         - Interactive mode / plain text mode   - Process       - A GitHub issue should be created to track the work-      - Wireframes are produced in Figma-      - Wireframes will be announced in Slack and linked in the GitHub issue well before they are complete for review-      - Schedule and conduct a research presentation meeting+      - Designs are produced in Figma+      - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review+      - Ensure designs meet the visual design checklist:+        - Ensure spacing is consistent and matches the 8pt grid system+        - Ensure colors match existing styles+          - If new styles are introduced, label them clearly+        - Review designs for accessability:+          - Color blind check

How would you like it to be checked?

rrhyne

comment created time in a month

Pull request review commentsourcegraph/about

Update checklists

 While asynchronous communication is a core attribute of remote work, key moments         - Interactive mode / plain text mode   - Process       - A GitHub issue should be created to track the work-      - Wireframes are produced in Figma-      - Wireframes will be announced in Slack and linked in the GitHub issue well before they are complete for review-      - Schedule and conduct a research presentation meeting+      - Designs are produced in Figma+      - Designs will be announced in Slack and linked in the GitHub issue well before they are complete for review+      - Ensure designs meet the visual design checklist:+        - Ensure spacing is consistent and matches the 8pt grid system+        - Ensure colors match existing styles

How about mentioning the text styles here as well?

Ensure text styles match the existing ones, if possible. Introduce new text styles only if really necessary. Remember to add them to the design system with proper description and ensure that they meet the accessibility standards.

rrhyne

comment created time in a month

issue commentsourcegraph/sourcegraph

Design templates for common page types

Thank you @rrhyne, great feedback :) I've added new iteration based on your suggestions. Please, see the comments in Figma as well.

I've created two propositions for Extension header :

  • bigger - more similar to the current header
  • condensed - new proposition that would reduce empty space in the top section

Please, let me know what are your thoughts on this change. Thank you!

Also, I've discovered an accessibility issue with our ghost texts (placeholders for text fields like 'search code..'). The current color doesn't meet the contrast standards. I've added a proposition of changes to the document as well.

christinaforney

comment created time in a month

issue commentsourcegraph/sourcegraph

Design templates for common page types

@christinaforney @rrhyne Please, review the designs. I've prepared the following:

  1. Analysis of our current headers (on Insights, Campaigns and Extentions, but also on other pages potentially effected by the header UI changes)

  2. Inspirations for breadcrumbs

  3. Propositions of the new Header.

Important points:

  • breadcrumbs will be present on all pages
  • file contains 3 visual propositions (with home icon, with page icon and with both). I'm looking for feedback on which one we should choose (the goals is to make it look good but not too overwhelming).
  • examples of use for Insights page and subpage. I will prepare the rest of the pages when we select the final style :)

Looking forward to your feedback! 🎉

christinaforney

comment created time in a month

issue commentsourcegraph/sourcegraph

Design templates for common page types

As the requirements for this project are well defined, some of the the research and testing phases will be eliminated to immediately begin design and development.

Step 1 - Understand the problem

  • [ ] Kick-off meeting

  • [ ] Review all the headers used currently in the platform and identify inconsistencies

Step 2 - Ideation

  • [ ] [Research] Competitive designs

  • [ ] Analysis of Sourcegraph pages structure - Interaction models doc

  • [ ] Create first proposition of Wireframes and submit for review (as a clickable prototype, most probably high-fidelity)

Step 4 - Visual design

  • [ ] Polish the designs, create dark mode, update the components library
christinaforney

comment created time in a month

Pull request review commentsourcegraph/about

Update research section

 While asynchronous communication is a core attribute of remote work, key moments       - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented   - Interview external users       - Where the project requires and time permits, conduct research with these users to inform your designs-  - Placeholder:-      - Additional research methods   - Customer requests and support tickets       - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)   - Analogous designs   - Competitive designs-  - Findings publishing and review-      - Findings should be recorded in google docs and announced in the corresponding team channel or #product on Slack-          - Research documents should contain a clear summary of findings and charts of supporting data are helpful.-      - If the size of the project requires, a review meeting should be held to discuss key findings.+  - Usability tests+    - When updating existing product features, first conduct usability tests to inform redesign decisions   - Process       - A GitHub issue should be created to track the work       - Research is conducted according to requirements-      - Publish research to Google Drive+      - Findings publishing and review+        - Findings should be detailed in a google doc and announced in the corresponding team channel or #product on Slack+        - Findings should contain a clear summary, links to resources and supporting data+        - Conduct a syncronous review meeting with key stakeholders based on side of project or importance of findings       - Announce research in Slack

@rrhyne It seems like announcing in Slack was already covered in line 45. Please, let me know if I understand it correctly.

rrhyne

comment created time in a month

Pull request review commentsourcegraph/about

Update research section

 While asynchronous communication is a core attribute of remote work, key moments       - As our users are developers, Sourcegraph developers make great interview subjects. However, we need to acknowledge that they do have biases about features and this research must be augmented   - Interview external users       - Where the project requires and time permits, conduct research with these users to inform your designs-  - Placeholder:-      - Additional research methods   - Customer requests and support tickets       - Our users are passionate and provide excellent feedback. Each project should utilize our collections of this feedback in [Productboard](https://sourcegraph.productboard.com/)   - Analogous designs   - Competitive designs-  - Findings publishing and review-      - Findings should be recorded in google docs and announced in the corresponding team channel or #product on Slack-          - Research documents should contain a clear summary of findings and charts of supporting data are helpful.-      - If the size of the project requires, a review meeting should be held to discuss key findings.+  - Usability tests+    - When updating existing product features, first conduct usability tests to inform redesign decisions   - Process       - A GitHub issue should be created to track the work       - Research is conducted according to requirements-      - Publish research to Google Drive+      - Findings publishing and review+        - Findings should be detailed in a google doc and announced in the corresponding team channel or #product on Slack+        - Findings should contain a clear summary, links to resources and supporting data+        - Conduct a syncronous review meeting with key stakeholders based on side of project or importance of findings       - Announce research in Slack

@rrhyne Good changes! I have only one suggestion here. It seems like announcing research in Slack is already mentioned in line 45. Maybe we can remove this line (48)? :)

rrhyne

comment created time in a month

created repositoryAlicjaSuska/github-upload

created time in a month

delete branch AlicjaSuska/github-slideshow

delete branch : my-slide

delete time in a month

create barnchAlicjaSuska/github-slideshow

branch : my-slide

created branch time in a month

delete branch AlicjaSuska/github-slideshow

delete branch : my-slide

delete time in a month

push eventAlicjaSuska/github-slideshow

AlicjaSuska

commit sha f9c47a9022afc1fcc5e5618ef4ee7704016d3349

Add Alicja Suska's file (#3) * Add: welcome message * Add quote

view details

push time in a month

PR merged AlicjaSuska/github-slideshow

Add Alicja Suska's file

created a branch, created a file and made a commit, and opened a pull request

+10 -0

1 comment

1 changed file

AlicjaSuska

pr closed time in a month

push eventAlicjaSuska/github-slideshow

AlicjaSuska

commit sha 9c62f880218be82731366eb89e42bb7a95f78676

Add quote

view details

push time in a month

pull request commentAlicjaSuska/github-slideshow

Add Alicja Suska's file

created a branch, created a file and made a commit, and opened a pull request

AlicjaSuska

comment created time in a month

push eventAlicjaSuska/github-slideshow

AlicjaSuska

commit sha cf8a98a3aaea1fa29d89917c87371f21f7b17a12

Add: welcome message

view details

push time in a month

create barnchAlicjaSuska/github-slideshow

branch : my-slide

created branch time in a month

issue closedAlicjaSuska/github-slideshow

Getting Started with GitHub

:wave: Welcome to GitHub Learning Lab's "Introduction to GitHub"

To get started, I’ll guide you through some important first steps in coding and collaborating on GitHub.

:point_down: This arrow means you can expand the window! Click on them throughout the course to find more information. <details><summary>What is GitHub?</summary> <hr>

What is GitHub?

I'm glad you asked! Many people come to GitHub because they want to contribute to open source <sup>:book:</sup> projects, or they're invited by teammates or classmates who use it for their projects. Why do people use GitHub for these projects?

At its heart, GitHub is a collaboration platform.

From software to legal documents, you can count on GitHub to help you do your best work with the collaboration and security tools your team needs. With GitHub, you can keep projects completely private, invite the world to collaborate, and streamline every step of your project.

GitHub is also a powerful version control tool.

GitHub uses Git <sup>:book:</sup>, the most popular open source version control software, to track every contribution and contributor <sup>:book:</sup> to your project--so you know exactly where every line of code came from.

GitHub helps people do much more.

GitHub is used to build some of the most advanced technologies in the world. Whether you're visualizing data or building a new game, there's a whole community and set of tools on GitHub that can get you to the next step. This course starts with the basics, but we'll dig into the rest later!

:tv: Video: What is GitHub? <hr> </details><br>

<details><summary>Exploring a GitHub repository</summary> <hr>

Exploring a GitHub repository

:tv: Video: Exploring a repository

More features

The video covered some of the most commonly-used features. Here are a few other items you can find in GitHub repositories:

  • Project boards: Create Kanban-style task tracking board within GitHub
  • Wiki: Create and store relevant project documentation
  • Insights: View a drop-down menu that contains links to analytics tools for your repository including:
    • Pulse: Find information about the work that has been completed and the work that’s in-progress in this project dashboard
    • Graphs: Graphs provide a more granular view of the repository activity including who contributed to the repository, who forked it, and when they completed the work

Special Files

In the video you learned about a special file called the README.md. Here are a few other special files you can add to your repositories:

  • CONTRIBUTING.md: The CONTRIBUTING.md is used to describe the process for contributing to the repository. A link to the CONTRIBUTING.md file is shown anytime someone creates a new issue or pull request.
  • ISSUE_TEMPLATE.md: The ISSUE_TEMPLATE.md is another file you can use to pre-populate the body of an issue. For example, if you always need the same types of information for bug reports, include it in the issue template, and every new issue will be opened with your recommended starter text.

<hr> </details>

Using issues

This is an issue <sup>:book:</sup>: a place where you can have conversations about bugs in your code, code review, and just about anything else.

Issue titles are like email subject lines. They tell your collaborators what the issue is about at a glance. For example, the title of this issue is Getting Started with GitHub.

<details><summary>Using GitHub Issues</summary>

Using GitHub issues

Issues are used to discuss ideas, enhancements, tasks, and bugs. They make collaboration easier by:

  • Providing everyone (even future team members) with the complete story in one place
  • Allowing you to cross-link to other issues and pull requests <sup>:book:</sup>
  • Creating a single, comprehensive record of how and why you made certain decisions
  • Allowing you to easily pull the right people and teams into a conversation with @-mentions

:tv: Video: Using issues

<hr> </details>

<details><summary>Managing notifications</summary> <hr>

Managing notifications

:tv: Video: Watching, notifications, stars, and explore

Once you've commented on an issue or pull request, you'll start receiving email notifications when there's activity in the thread.

How to silence or unmute specific conversations

  1. Go to the issue or pull request
  2. Under "Notifications", click the Unsubscribe button on the right to silence notifications or Subscribe to unmute them

You'll see a short description that explains your current notification status.

How to customize notifications in Settings

  1. Click your profile icon
  2. Click Settings
  3. Click Notifications from the menu on the left and adjust your notification preferences

Repository notification options

  • Watch: You'll receive a notification when a new issue, pull request or comment is posted, and when an issue is closed or a pull request is merged
  • Not watching: You'll no longer receive notifications unless you're @-mentioned
  • Ignore: You'll no longer receive any notifications from the repository

How to review notifications for the repositories you're watching

  1. Click your profile icon
  2. Click Settings
  3. Click Notification from the menu on the left
  4. Click on the things you’re watching link
  5. Select the Watching tab
  6. Click the Unwatch button to disable notifications, or Watch to enable them

<hr> </details>

<hr> <h3 align="center">Keep reading below to find your first task</h3>

closed time in a month

github-learning-lab[bot]

push eventsourcegraph/about

AlicjaSuska

commit sha 0e104629fb274063d43c0f2fea6be2db5ae531a8

Added: Alicja to the Team page

view details

push time in a month

create barnchAlicjaSuska/github-slideshow

branch : master

created branch time in a month

created repositoryAlicjaSuska/github-slideshow

A robot powered training repository :robot:

created time in a month

push eventAlicjaSuska/CV

AlicjaSuska

commit sha 446cb4286b98a64a4e28585b794236ef64747336

wrong name

view details

push time in a month

push eventAlicjaSuska/CV

AlicjaSuska

commit sha da59d6807beaad8ca289e18f27178336d55f8578

wrong name

view details

push time in a month

push eventAlicjaSuska/CV

AlicjaSuska

commit sha 7de05ad39666c4c7fbee2906df906b870df7f7db

new images file

view details

push time in a month

push eventAlicjaSuska/CV

AlicjaSuska

commit sha e92b9f27abff84890e1cd31b27c7b76d2cd60126

New image file

view details

push time in a month

push eventAlicjaSuska/CV

AlicjaSuska

commit sha 6c6f46366a5af7fddf35854f182bd057aa86a2bf

Add initial CV files

view details

push time in a month

create barnchAlicjaSuska/CV

branch : master

created branch time in a month

created repositoryAlicjaSuska/CV

created time in a month

issue commenttoggl/ios

Page sheet transition discussion

Changes is settings will be only visual. I'm not planning to change the behaviour :)

sofokli1

comment created time in 2 months

issue commenttoggl/ios

Modal card transition discussion

Also, @sofokli1 you've mentioned that dragging down the handle will close the view. It is a good idea (wasn't designed this way initially). Anyways, it should trigger the alert about unsaved changes as well

sofokli1

comment created time in 2 months

startedAlicjaSuska/carful-landing-page

started time in 3 months

startedAlicjaSuska/carful-landing-page

started time in 3 months

issue commenttoggl/android

Figure out animations/transitions for The Wheel ™

yes, that's what I mean. Thank you @daividssilverio :)

daividssilverio

comment created time in 3 months

issue commenttoggl/android

Figure out animations/transitions for The Wheel ™

@daividssilverio agree with you on almost everything. the only issue are the spinning handles. How about we just make them 'pop' slightly - make them 4px smaller, than bigger

daividssilverio

comment created time in 3 months

issue commenttoggl/android

Figure out animations/transitions for the StartEdit related views

@daividssilverio by dropdowns I mean both - suggestions and those from project/tag pills

about the wheel - we should fad it in and slide the view a little so that the whole wheel is visible :)

daividssilverio

comment created time in 3 months

more