Syntax

[ddturner]

Looks great!

Issues:

1. It's not clear in the video if there's spacing before and after the colon to make groups into a symbol. If so, that's seems inconsistent with the $ for dynamic text naming convention.
   Recommendation: make "Make Into Symbol" and "Make Into Dynamic Text" contextual menu items.
2. Key command combo to step back/undo/"Change From Symbol".

[tisho]

Thanks for the feedback @ddturner!

On 1: it doesn't actually matter if you have a space before or after the colon. The colon notation was inspired by two things: 1) the way you'd specify that an object inherits from another object in Objective-C (e.g. @interface Person : NSObject, and 2) Ruby's symbols (e.g. :property). It was important to me that the "tag" didn't require you to match parentheses or make you spread your fingers too far on the keyboard.

The dynamic layer's prefix comes from languages like perl and php, where $ is used to denote variables. I don't actually see why the two need be consistent, because they really concern different things - one denotes symbols, the other one denotes dynamic layers, which can be contained in symbols. In a programming language, one would be a class, the other one – a variable.

That said, I like your suggestion about "Make Into Symbol" and "Make Into Dynamic Text". It would probably help people who aren't familiar with the tagging patterns, even if renaming through Cmd+R is often faster.

On 2: The plugin actually works with Sketch's default undo stack, so I have no control over stepping back/undoing. You can use Cmd+Z to undo.

[ddturner]

Hi and thanks for the reply.

You’re not wrong in your thinking or observations (and CSS and Javascript, which are more likely familiar to users of Sketch, also use symbols for inheritance), but that’s not the mental model of most of the types who’d be using Sketch. Think progressive disclosure: people could have the option to type this all in in a command-line-like way, but enable people who don’t want to memorize rules to click and get on with their main goal, which is to make visual images.

Renaming through Cmd-R is faster for you! But not for me. Remember, most design people don’t have both hands on the keyboard, but one there and one on the mouse/trackpad/tablet.

On Jan 7, 2014, at 3:44 PM, Tisho Georgiev notifications@github.com wrote:

Thanks for the feedback @ddturner!

On 1: it doesn't actually matter if you have a space before or after the colon. The colon notation was inspired by two things: 1) the way you'd specify that an object inherits from another object in Objective-C (e.g. @interface Person : NSObject, and 2) Ruby's symbols (e.g. :property). It was important to me that the "tag" didn't require you to match parentheses or make you spread your fingers too far on the keyboard.

The dynamic layer's prefix comes from languages like perl and php, where $ is used to denote variables. I don't actually see why the two need be consistent, because they really concern different things - one denotes symbols, the other one denotes dynamic layers, which can be contained in symbols. In a programming language, one would be a class, the other one – a variable.

That said, I like your suggestion about "Make Into Symbol" and "Make Into Dynamic Text". It would probably help people who aren't familiar with the tagging patterns, even if renaming through Cmd+R is often faster.

On 2: The plugin actually works with Sketch's default undo stack, so I have no control over stepping back/undoing. You can use Cmd+Z to undo.

—
Reply to this email directly or view it on GitHub.

dan turner
MIMS 2011
School of Information at UC Berkeley
415.606.4811
www.twoangstroms.com
@DDT

[tisho]

Dan, you make some very good points.

Having naming patterns define symbols/dynamic layers isn't ideal in the first place, but is the only thing we can rely on right now because of the limitations of the plugin API. I'm sure that whenever the folks from Bohemian Coding have an official implementation of the symbols feature, it would be implemented very similarly to what you suggested – there would be no need to remember anything and turning a layer group into a symbol will be just a click away in a contextual menu or easily accessible through a shortcut.

While we wait for that, I could add a shortcut that would automatically append an auto-generated symbol name to the layer group you've selected in order to turn it into a symbol (e.g. you'd select a group named "button", press, say Cmd+Shift+T and the name of the group will change to "button : sym1389164856"). This would enable "one-handed use" and save you the trouble of naming your layers. There are downsides to that, of course. Your layer list will be littered with nonsensical names, for one. And I, personally, feel that we as designers should be more intentional about naming in our work (that's an entirely different conversation). But it will improve the workflow for people who choose to use the plugin this way, so I'm considering making it part of the next release.

How does that sound?

Thanks for your input, again.

[ddturner]

Hi Tisho,

That sounds pretty good! Users could always rename the symbols, right? Or could you set it up so that symbols get default names the same way layers do? That is, "Symbol 1", "Symbol 2", etc.?

On Jan 7, 2014, at 11:11 PM, Tisho Georgiev notifications@github.com wrote:

Dan, you make some very good points.

Having naming patterns define symbols/dynamic layers isn't ideal in the first place, but is the only thing we can rely on right now because of the limitations of the plugin API. I'm sure that whenever the folks from Bohemian Coding have an official implementation of the symbols feature, it would be implemented very similarly to what you suggested – there would be no need to remember anything and turning a layer group into a symbol will be just a click away in a contextual menu or easily accessible through a shortcut.

While we wait for that, I could add a shortcut that would automatically append an auto-generated symbol name to the layer group you've selected in order to turn it into a symbol (e.g. you'd select a group named "button", press, say Cmd+Shift+T and the name of the group will change to "button : sym1389164856"). This would enable "one-handed use" and save you the trouble of naming your layers. There are downsides to that, of course. Your layer list will be littered with nonsensical names, for one. And I, personally, feel that we as designers should be more intentional about naming in our work (that's an entirely different conversation). But it will improve the workflow for people who choose to use the plugin this way, so I'm considering making it part of the next release.

How does that sound?

Thanks for your input, again.

—
Reply to this email directly or view it on GitHub.

dan turner
MIMS 2011
School of Information at UC Berkeley
415.606.4811
www.twoangstroms.com
@DDT

[tisho]

Unfortunately, no. To have the naming scheme you suggest, we need to be able to preserve state between different executions of a command. So every time we execute the command, a counter gets incremented by 1, so the next time we need to name a symbol, we just use the current value of the counter. Unfortunately, that's currently impossible in Sketch since every command execution is essentially a blank slate. This is the reason why in the example I gave, I used a timestamp. It should be sufficiently unique, even if it's not the best for readability.

I think I'll add a rename symbol command, too, which will bulk-rename all instances of a symbol.

[bomberstudios]

Regarding your "every command execution is essentially a blank slate": you are right, but there's a workaround : )

Here's a bit of code I'm using on an in-progress plugin, where I need persistence between sessions:

var defaults = [NSUserDefaults standardUserDefaults],
    default_values = [NSMutableDictionary dictionary];

[default_values setObject:"bar" forKey:"foo"];

[defaults registerDefaults:default_values];

log([defaults objectForKey:"foo"])

Still not as good as per-document persistence, but you could fake it by using the document's name as a key (probably not worth the pain IMHO, but YMMV)

[tisho]

This is a great find, Ale! Thanks for sharing! It will definitely come in handy.

[bomberstudios]

Glad you like it. BTW, would you be interested in joining the Sketch Development mailing list I've set up at http://sketchplugins.com? I have big plans for the site, but I'll start small : )

[tisho]

Just did!