Abstract Deprecated

Abstract is a design workflow platform providing modern design teams with one place to version, manage and collaborate on (Sketch) files. The design chapter of George Labs uses Abstract.

Setup

1. As a George-Labs designer, sign up with your George Labs email address at abstract.com.
2. Download Abstract.
3. Wait for (or request) an invite for the George Labs organisation.

Seats

Abstract has two types of seats available for each person invited to an organization. Learn more on abstract.com about seats and project permissions.

Contributors

Contributors (=George core designers) have access to all features including creating branches, editing files, committing changes, and updating/merging branches.
For a contributor to accept the invitation, an unused seat needs to be available.

Viewers

Viewers (= developers, product owners,…) can review work, leave comments and annotations, export files or open them un-tracked.
Viewers are free and you can have an unlimited amount of them.

Roles

Three types of roles are available to assign to each Viewer or Contributor that is part of an organization. One type of role can be assigned per seat.

Administrators

Administrators are responsible for managing the Abstract account for an organization.

Members

Members are typically company employees who have access to Team Projects within an organization. - In the context of George, we do not use the role of a member so far.

Guests

Guests have access to one or more Projects they’ve specifically been invited to. Guests do not automatically have access to all Team Projects within an organization. Guests must be invited to specific Team Projects or Private Projects.

Invitations

It is considered best practice to invite a new user to a specific Abstract project (and not invite someone to the Organization) - this way they become “Guests” in Abstract (which is the user role everyone who is not a George-core designer should be assigned to).

New Abstract users

1. Open Abstract.
2. Go to the project to which you want to invite a new user to.
3. Go to members (left side navigation).
4. Click on “Invite People” (top right corner).
5. In the modal, click on the tab “Invite Guests”.
6. Check the radio button “Guest Viewers”.
7. You will manage from here…

Existing Abstract users

1. Open Abstract.
2. Go to the project to which you want to invite a new user to.
3. Go to members (left side navigation).
4. In the modal, search for the Abstract user to add to the project.
5. Click on the “Add” button next to the respective user name.

Best practices

Structuring content

As most squads have different scope and needs when it comes to design, it is suggested that the squad designer of each squad finds a way to structure the squad’s design files accordingly, but should keep in mind the best practices

File naming conventions

• Once you upload files to Abstract, strip them of version numbers (e.g. New_Transfer_AT.sketch instead of New_Transfer_AT_v8.sketch, as the history of the file can be accessed via Commit History inside Abstract).
• Once files from the George Labs GroupDrive are hosted in Abstract, rename the highest folder possible on the George Labs GroupDrive with the suffix _ABSTRACT to mark that the designs on the George Labs GroupDrive are outdated.

File names in Abstract must follow this pattern

[Country]_[Platform]_[FeatureName](_[OptionalInformation]).sketch

Mandatory information

• Country: CORE (= all countries)/AT/CZ/SK/RO
• Multiple Countries: e.g. AT_CZ
• Platform: Web (including responsive)/App (= native Android + iOS)/iOS/Android
• Feature: FeatureNameInCamelCase

Optional information

• Misc: Webview, Template, Playground, Experiment, Onboarding, Printing, Signing, Modal, etc.

Example: AT_App_Appointments_Webview.sketch
Example: CORE_Web_Watchdogs.sketch

Collections in Abstract must follow this pattern

#[Ticket-Number]: [FeatureName] (Misc)

Example: #GRSK-3712: SecuritiesStatements

Component specification in Abstract must follow this pattern

• #[GDSWEB-Ticket-Number]_[FeatureName].sketch

Example: #GDSWEB-860_Snackbar.sketch

Branching and commits

• Branch with achievable intent and apply clear naming conventions
• Commit often (=several times a day) and provide context (not only for your team but also for yourself)
  • Write the summary line and description of what you have done in the imperative mode, that is as if you were commanding someone. Start the line with Fix, Add, Change instead of Fixed, Added, Changed.
  • If it seems difficult to summarize what your commit does, it may be because it includes several logical changes or bug fixes, and are better split up into several commits using git add -p.

GDS Sketch libraries

Branch names will be used to write the changelog for the Sketch libraries hosted in the George Design System. The branch name (or at least the merge message) has to be meaningful, please also consider:

• Use the tags BREAKING (DEPRECATED or WIP) if applicable.
• If there is a Jira ticket for the Abstract branch, start the branch with the Jira ticket number (e.g “GDSWEB-1234 | …”).
• Mentioning the affected library name is mandatory (G-Browser, G-App).
• If the change is only affecting any kit (Sketch file), the affected Sketch file (G-Browser-Kit, G-App-Kit) has to be mentioned.
• Some “keywords” that should be used are “Added”, “Fixed”, “Updated”, “Chore”.

Some examples:

• “GDSWEB-1234 | Added contact/info to G-Browser”
• ”BREAKING Refactored function_cards/* to make use of SmartLayouts in G-Browser”
• “GDSWEB-1234 | Updated colours for primary buttons (auto- and manual width) in G-Browser”
• “Fixed typo in override name of cells in G-App”