New Mac beta: v99.5 available now

Newsroom Sketch Labs
1

Hey everyone :wave: We have a new Mac app beta out and ready to try!

How do I get it?

You can download our beta from sketch.com/beta — you’ll need an active subscription to use it. If you already have a beta build, you can open it and follow the prompts to update.

How do I share feedback?

If you run into any issues, the best way to share them with us is to click on the :lady_beetle: Send Beta Feedback button in the toolbar. This should open an email template in your email client of choice to fill and send to us.

If you experience a crash, please do send the crash reports that appear when you reopen Sketch (both Apple’s and our own) — we read every single one of these and use this information to make Sketch more stable.

What’s in this beta?

In this release, we’re fixing bugs, preventing crashes, and shipping a collection of small quality-of-life updates.

Saving documents

You no longer need to manually save Workspace documents. We’ll automatically save your changes while you’re working and when you close a document.

You can still create new versions using File > Save Version (⌃⌘S) and add a description, giving everyone a quick way to see what’s changed when browsing a document’s version history in the web app.

In the web app, Viewers and Guests can click the See Latest Version button to get an up-to-date preview of a document that Editors are working on but haven’t created a new version of in a while. Star a version in your document so Viewers and Guests only see the latest preview of the starred version, leaving you in control of which versions Viewers and Guests can see.

Foresight :handshake: Tidy

We’ve added Foresight to the Tidy button in the Inspector — you’ll now see a preview when you hover over it, giving you a better idea of how your changes will look. Tidy now also works on both the horizontal and vertical axis, making it even easier to align layers.

You can find a full list of release notes, including changes and bug fixes at sketch.com/beta

We hope you enjoy our latest beta — and look forward to your thoughts and feedback!

10 Likes
2

Nice little update. MMB for panning would be a lovely addition before pushing Sketch 100 :grin:

3

I’ve given the latest betas a run for the past couple of months, and although I appreciate the new Tidy Foresight, the act of ‘Tidy’ has become unusable for me.

Tidy now also works on both the horizontal and vertical axis, making it even easier to align layers.

Tidy no longer respects just the horizontal or just the vertical spacing, and attempts to overly align both at the same time, which is desirable about 0% of the time. I have resorted to manually entering values in either the horizontal or vertical input fields and hitting return/tab. To speed up that process, I went back to using a plugin called Distributor v1.2.3 (PEZ/SketchDistributor on GitHub) so that I can use a hotkey to invoke precise horizontal or vertical spacing. Now, in my workflow at least, all of the recent Tidy updates are going unused. I still use Smart Layouts as much as possible, so getting the initial ‘tidied’ positions started is important.

Some options for improving this new feature:

  • Revert the Tidy behavior of distributing only the horizontal or vertical spacing, using a best guess.
  • Revert the Tidy behavior of distributing only the horizontal or vertical spacing, using a best guess, but introduce a modifier key to the Tidy button to make it work on both axes.
  • Provide users with a setting to always Tidy both axes, or use the best guess.

Bonus:

  • Allow users to enter numerical values in either horizontal or vertical spacing fields before needing to hit the Tidy button. Right now you can only enter values in a field if it is not blank.
  • Add default hotkeys to target just the horizontal or vertical input fields. Similar in ways to using the SketchDistributor plugin above.
  • Add default hotkey to invoke the Tidy command. Right now you must add a custom one via System Settings.
  • Add the ability to numerically Tidy as part of the Smart Layout creation. e.g. Select items > cmd-L > type 40 > right arrow.

Thanks for the recent 99.5 beta work, the extra polish is appreciated.

4 Likes
4

Hey Joe,

Thanks for taking the time to write this elaborate post; these are good suggestions! They will be useful when we revise this feature at some point in the future.

And we’re glad to hear the extra polish is appreciated.

Thanks again.

5

Foresight is a thoughtful feature given that tidy can sometimes give unpredictable results. While it can be a quick way to clean up a large grid, however I find myself deeply missing the Butter plugin (support was lost around v97).

You have several commands in the Arrange > Align menu, but are missing the most useful one, buttt or 0px inter-spacing. Yes, you can go to the properties panel and type in “0px” but it’s slow and tedious. This is a VERY HIGH USE action as UIs are 90% lists. Just putting this in the menu would allow expert users to set hot key and move fast.

Adding 4 simple commands (buttt up, down, left & right) would also accomplish what the new smart-layout is trying to do, but without all the setup, bugs, and idiosyncrasies.

Please add these :pray:

Screenshot 2024-01-09 at 9.41.38 AM
Screenshot 2024-01-09 at 9.41.38 AM984×920 268 KB

6

+100000 to Joe’s suggestion. Please revert the Tidy command to its previous behaviour, where it solely managed the spacing between layers in a single row or column, without affecting their alignment.

1 Like
7

Updating libraries is very cumbersome in the 99.5 beta…

I get that working on large teams with multiple people updating libraries, things can get can confusing. There’s a desire to add some safety around shared libraries as it can impact many things for many different people in many different files, but these updates seem to overfit for a particular user type (large teams with novice users) while being detrimental for small proficient teams trying to work smart and fast.

Also this doesn’t actually fix the underlying problem of knowing how an edit to your library will impact other files. It only makes updates more difficult to do, and therefore less frequent (which is a bad thing).

Honestly, I’d argue this actually complicates the problem, because you now have out of sync libraries to deal with. And they can be out of sync in two ways…

  1. Saved, but not versioned…
  2. Versioned, but not starred…

Let’s not complicate things.

Current methods to update a library…

  1. ⌘S to save (locally only?)
  2. Click on the toast before it vanishes to create a version (saves on cloud?)
  3. Add an optional commit message (nice)
  4. Check star for libraries to function properly (extra work, easy to forget)
  5. Click “Save version” button

Ideal Method…

  1. ⌘S to saves (version this on cloud if on wifi, otherwise save locally)
  2. Add an optional commit message with the star already checked (important!)
  3. Click “Save version” button

*not having the star checked by default undermines the entire idea of libraries.

Starring Versions
Staring a version to use as your library genuinely seems useful. You could theoretically go back and star an old version when edits produce expected outcomes. However, for small teams (or single person use) I would want every save starred by default. There’s absolutely not need for me to not star it. It just delays me from discovering any problems. If you really want to persevere this feature it should be an opt-out rather than opt-in (maybe a setting level preference?).

Saving vs Creating Version
I’m assuming “⌘S” locally saves to your disc and “^⌘S” saves to the cloud? That seems to be what’s happening, but it’s unclear. Having two commands seems totally unnecessary. I want one command, if I have internet I want to save to the cloud, If I don’t then save locally as a fallback. This applies to both libraries and regular docs.

8

Hi @everydayslang

Thanks so much for taking the time to share feedback in a very thorough and detailed way. I think it’s worth mentioning the idea behind this latest change and also point out some nuances around Saving vs Creating a version and Versioning and Starring.

Saving vs Creating a Version

So first things first, why did this change? Well, as computer users creating documents, it’s very common to hit ⌘S frequently, sometimes very frequently. What happened before is that a new version was created for every time you hit ⌘S, even if you only moved a layer 1px, and the result was that you could end up with a lot of nearly identical versions that could complicate navigating version history when needed.

In 99.5 all your changes are saved automatically and sent to the Workspace, but a version needs to be explicitly created for these changes to be visible on the Web app. Now you may ask what if you forget to create a version? Or if you close your library and didn’t create one? Sketch will create one automatically in these cases; you’ll see it as “Autosave” in the version history.

If someone else is seeing your file in the Web app and you haven’t created a version, Sketch will detect that the file has changes, will alert you about this and create an Autosave version so the changes can be seen.

The idea behind this is to help navigate document version history, even for individual users or small teams, by making a conscious decision to create a version and add the commit message if needed.

If you use the shortcut ⌃⌘S it’s really fast. Then you just have to press Enter or add the optional commit message and create the version.

Creating versions Vs Starring

Starring every version is useful for sharing a document with Viewers. For instance, if developers with Viewer access need to see past versions, you’ll need to star them. But if that’s not necessary you can just create new ones without starring them

If you star a version in a library and then push more changes, you’ll need to star that one too or you won’t get the library updates even if you’re the author of the file.

In a sense, starring versions in libraries can add an extra step compared to having no starred versions.

About making starred versions opt-out, the opposite scenario can take place: if you just want others to see the latest version and if you forgot to opt-out, they can see things you didn’t want them to.

We’d love to hear your thoughts and feedback about this. Thanks again for sharing this

9

Hey Jorge! What’s up? Thanks for this explanation. It confirms some of my assumptions and clears up some of my questions.

Saving vs Creating a Version
Using an unfamiliar hotkey for creating a version will definitely cleanup unwanted clutter in version history. Years of conditioning has definitely made us all trigger happy with ⌘S. However, my personal experience with using the version history has been rather good thus far. I use I both when I need to restore a file or just reference something from the past. There definitely are spurts where many versions were saved as well as long pauses where nothing happened, but with the date and person’s avatar I’ve had no trouble pinning down what I need. In fact that information is quite interesting both from a narrative and productivity standpoint I kinda like seeing those artifacts.

Creating Versions vs Staring
With starring versions, I honestly hadn’t been thinking about how it affects Viewers. I’d been solely thinking about myself as well as other Editors. Generally I don’t mind working out in the open, but I do have a coworker who adds screenshots to Asana tasks as a way to artificially achieve this privacy/permanency of starring a version, so there definitely is a real need there. But also I didn’t realize that you could star more than one version, I assumed starring one removed it from the previous (just thinking like an Editor). So stars are actually doing two jobs. For Viewers they give visibility. For Editors the last star gives access to reusable components (e.g. symbols, styles, colors). Question, can you choose a version that’s not the latest for Editors to use? Probably not, huh?

My dissatisfaction with this current setup is from the POV of an Editor. Libraries have always been slow to sync. I get it there’s a lot happening, but to add friction to this process is like rubbing salt in a wound, I’m already impatient, and now I have two additional steps. Gahhh!

I’ve honestly used this feature successfully before, but today could not figure out why my library was taking forever to sync. I saved, didn’t work. Oh yeah, make a version, still didn’t work. Then I went into trouble shooting mode (which means I’m not getting work done). Finally, I bothered to read the text at the bottom of the modal. Duh.

I should say that I’m current working from the beta app for one company and the production app for the other as a way to keep separate workspaces (which is nice) so I am back and forth a lot, but I there has been this feeling of dread associated with the beta. It wasn’t until today that I stopped to really think about what was causing it.

My question to you is, can you achieve these new goals you set without causing this disruption for the Editors? They are your more important user type, in that Viewers would not have anything to view without Editors first doing their thing…

  1. Suggestion for Saving vs Creating a Version if you really want to clean up that list (I think it’s fine) just group the list items for a given time range. Yes, users will have to untwirl it, but that happens once every few weeks or so whenever there’s a problem. ‘Saving’ is an extremely high frequency action. Creating friction there is a huge disruption.

  2. Suggestion for Creating Versions vs Staring maybe separate the two different jobs? Maybe use an eye icon for viewers visibility and keep the star icon for the active library? That actually might help people understand both features better. But in reality, I don’t expect many Viewer to be looking at my libraries. The interesting thing for Viewers is in my regular project files (e.g. the latest product updates). My libraries are just branding materials (colors and logos), custom icons, employee headshots, logos for partners/competitors that I reference to make my life easier. Yeah, ideally they’d go in a grab that stuff when they need it, but no matter how organized I keep those files they’re going to ask me to export a png/svg rather than go looking themselves. So what I’m saying is maybe for libraries keep the Editor as the priority, and for regular project files keep the Viewers as the priority.

Hope that helps :v:

10

One other thing, so, after I’m happy with changes I’ve made to a library I’ve made the following error…

  1. Saved
  2. Created a new version
  3. …but forgot to star the version!
    When this happens saving again doesn’t give me the toast in the upper right hand corner to easily create a new version. I have to go make a fake edit in the document somewhere to reset it.
11

Hey Stephen, thanks for sharing.

It’s interesting to read how you perceive (and are using) these features. Overall, there is a lot we could or should add to versions and the way we manage them. But it’s also tricky to get it right.

I think this could be a good topic for the Suggest an Idea section so others can also weigh in and help us get a broader view on how versions, saves and stars are used. Preferably, picking a few more concrete points such as the 1st and 2nd point you made.

1 Like
12

Just resurfacing this post from a while ago. Butter is still broken and the arrange options in Sketch are still rudimentary. This seems like an extremely low lift for a gigantic time saver.