There’s a discussion – or should I say I would like there to be a discussion – on user preferences for the pattern editor.
The specific case here is whether or not the pattern editor should show the side menu by default when the screen width is above a certain threshold, or not.
It’s a discussion where there is no obvious right or wrong answer, and different contributors have different opinions.
There is of course a different approach, which is that rather than force a certain way upon the users, we allow them to pick what works best for them. Well, they can already pick today, but we do not store that anywhere, so every time you start a new pattern, you have to (for example) set the side menu again, or configure the seam allowance you prefer, and so on.
One option would be to allow users to set certain ‘defaults’ in their account that apply to the editor/new patterns. Things like whether they want the side menu or not, whether SA should be on or off, how large it should be, default paper size, and so on.
I’m trying to gauge how big the need for this really is. Because every time we ask “we could add that” people say yes, because to them there is no price to pay in complexity or overhead. So it’s not all that useful to ask people whether they want something. Who doesn’t want free stuff?
The question is more, how big of an annoyance is it that you have to (for example) always toggle the side menu, or always set your preferred SA, and so on.
If it annoys the hecks out of you, then please let us know
For me personally, this would be an “Oh, that’s neat!” and save maybe a few seconds per new pattern, but it’s definitely not critical in any way, nor is it much of an annoyance
The menu on the right (I added an orange frame around it) is the same menu as the one in the top editor menu (which also has an orange frame).
This menu is specific to a certain view, unlike the view menu (the top-left button that says ‘Draft Pattern’) which is present on every Editor view.
The draft menu (the one in the orange box on the right) is hidden by default, but you can click a toggle or enter the UI Preferences menu to show it.
The question is whether defaults for the Core Settings and UI Preferences menu should be something users can store in their account.
If you feel you lack information to weigh on this, you don’t have to feel compelled to weigh in
I think it may be useful to store certain things on your account. SA and paper size are right up there. It would remove annoyance and possible incorrect prints if this is a stored preference for the user. It could be part of a on-boarding dialogue for new users. There seem to be a good amount of questions around SA from new users. And incorrect paper size is also a recurring theme.
I’d love to enable the side menu by default (since I find that easier to use), and I’d also love to set the seam allowance to 7 mm by default, since that makes the most sense with the markings for my overlocker (and 7mm seems to be a very common size in Europe anyway). It’s easy to create a new pattern and then forget to set it.
My first thought is that “it would be nice” to be able to store desired Core Settings and UI Preferences for my account. However, it isn’t necessary. I think that the annoyance factor of having to change settings each time is minor.
Unrelated tangent: I do feel strongly that default settings should exist at some point, either per-user or site-wide. It is a nice sentiment to say that, for example, we shouldn’t make assumptions about whether the user wants metric or imperial units or favor one over the other by setting one as the default. However, at the end of the day, the UI needs to start with some default behavior for the sake of consistency. Removing default settings and instead having the UI start with no settings at all seem to have resulted in a number of bugs and inconsistent behavior.
Not annoying at all. No hecks are going to breach their containment over this.
Something a bit higher on my wish list would be a pattern export option for projectors. It’s easy enough to work around (export for editing, and edit to add blank margins and a calibration box) but automation would be welcome.
I’m still very new here, and wary of making too much noise too soon. I mentioned the projector thing mainly to put the side menu thing into perspective.
It is a nice sentiment to say that, for example, we shouldn’t make assumptions about whether the user wants metric or imperial units or favor one over the other by setting one as the default.
Without wanting to dismiss the sentiment, the example of units is a bit awkward here because units are an account setting. It applies outside the editor too, for example when creating measurements sets, updating measurements and so on. So units are kept in the account, and inside the editor we use the units that are the ones set in the account by default.
(Default) Editor settings
This is not about things like units (those are account settings) but about things like “Should the side menu be shown?” or “What should the default seam allowance be”.
This is the sort of stuff I wanted to have a discussion about (but I’m glad to hear/read people’s thoughts/frustrations on other things).
Editor initial state
I think this is what is causing the most grief. Because it’s one of those things where I’ve put my foot down and said: No, we’re not doing that, we’re doing this. And that has caused some new bugs, and now people are saying “All of this is caused because Joost doesn’t want defaults”.
It is 100% OK to question my choices. If anything, I think it’s an important task for all contributors, because if I cannot explain why, then it probably means it was not a great decision. So I count on all of you to keep me from doing things that make no sense.
However, in this case, I think it does makes sense, so I will try to explain better
Essentially, I think that there is a misconception about “defaults” vs “initial state”. An example will clarify this, and let’s use units in our example:
Alice logs in to FreeSewing.eu and fires up the pattern editor. Their account settings indicate they prefer imperial units. The editor should respect those choice, so “imperial” is default, although Alice can still switch to different units.
Bob fires up the FreeSewing studio and opens the editor. We have no account info for Bob, so we use metric units as default, although Bob can still switch to different units
So you could argue that in both cases, the “default” is different. For Alice the default should be imperial, for Bob, it should be metric.
We can address this seemingly challenging situation by initializing the editor with a certain state. Like we can say: start up with imperial units.
The thing where I put my foot down was against a trend that was starting to add an increasing amount of “initial” state to how we start the editor. People were doing this to address UI bugs like “you need to click the units icon twice to change the units”, which happens because:
units are undefined
Click the icon once => units are now metric
Click the icon again => units are now imperial
That is a UI bug that really hinges on how we handle uninitialized state. (units being undefined). The solution that people implemented was to carefully initialize state (in other words, make sure that units are always set).
Where I stepped in was to say: No, we are not going to carefully initialize the editor state, because it actually papers over other bugs where components are not properly handling uninitialized state. The fix for clicking twice to change the units is not to initialize the state 3 levels of abstraction above, but to actually make sure that that toggle or menu item or whatever behaves as expected.
Had I been smarter, I would have drawn that line in the sand from the very beginning. But I’m not, and so it wasn’t until that initial state starting to grow in complexity that I made that decision and in one fell swoop yanked out the initial state that had been added, and in doing so brought back all the bugs that were solved by setting the initial state.
That was never going to be a popular move, but I think that perhaps if I had explained my reasoning better, it would have created less frustration.
I hope that I did a slightly better job at explaining why I think in the long run, this will yield better results, but I am open to discuss this further – perhaps on a call – with anyone to whom this was an upsetting decision.
I’m not sure I actually understand the problem or issue well, but I won’t let that stop me from jumping in here.
I find this an interesting thing. To me, there are three things you can do with uninitialized states:
Do nothing. Bugs could appear, it could pretend that there is a ‘default’ state, random things could happen.
Have a defined default state.
Detect that it is uninitialized, and ask for the value the user would like.
(Something else?)
The third option could be a lot of work. I think the best approach is some combination of site-wide defaults, and account-based defaults. Or even go with site defaults that can be overruled by account defaults for the same setting. SA is 1cm if you haven’t changed it, but you can set it to 15.8mm if you’re used to 5/8". Side menu is normally hidden, but you can always have it shown if you choose so.
