Wording: "detail" vs "pattern piece"

translations
terminology

#1

I started contributing to the french translation, and as a usability specialist (sometimes called UX specialist, or other complicated names alike), I am highly sensitive to concepts/wording. Could someone provide me with explanation regarding the differences/relations between:

  • a “Detail”
  • a “Pattern piece”

BTW, regarding the existing french translation, it appears that 3 terms are used:

  • “Pièce de patron” in place of “Detail” in the left toolbar
  • “Elément de patron” (and its companion “Nouveau élément de patron”) in place of “Pattern piece”
  • “Isolation” in place of “Details” mode. Apparently, these terms may not be consistent together. Once the difference between “detail” and “pattern piece” will have been made clear, maybe we could find a consistent way to translate it in french?

#2

Word Detail was used because i made straightforward translation from ukrainian language. Native speakers usually call it a piece. In this case it is combination of seam line, seam allowance, passmarks, labels and grainline. It sort of shape.

Word Pattern piece doesn’t have equivalent in my language. At least i don’t know such. This is a sub pattern in form of independent pattern. Usually sleeve, front and back, collar etc. It is place where all calculations made.


#3

I have always understood the detail to mean the nodes and curves that are selected make up the individual part of the pattern. And the pattern piece is the finished product of the individual part of the pattern.

For example: A whole pattern is made up of various pieces of pattern (pattern pieces) that are created by choosing the details relevant to the pattern piece once the drawing of the pattern has been done.


#4

When you buy a traditional (consumer) pattern, it comes as a number of pieces of tissue paper.

My guess is that originally it was envisaged that a PatternPiece would give rise to a fully marked up drawing that would be the equivalent one of those pieces of tissue paper. Or at least, that was how the translations worked out.

However, it is far more useful to draw the front and back bodice parts (etc.) in one drawing, and to generate multiple pieces from that drawing. I assume that this is why one PatternPiece can yield several Details. It is the Detail that is the equivalent of a piece from a traditional pattern.

In fact, it is so useful to draw the aspects together that I’ve only used a separate pattern piece where there is little geometric connection, e.g. a belt, bow or pocket. Or if it were a pattern for a mens suit then you could imagine using separate “PatternPieces” for the jacket and trousers, but each of these would yield many “Details”. As Dismine says, the “PatternPiece” is really a sub-pattern, quite independent except that it shares measurements and increments.

You could argue that it would be clearer if a PatternPiece were renamed to something else, perhaps a “drawing”, and a Detail were renamed to a “piece”.

Just my thoughts from a fairly new user.


#5

I think of it this way:

Formulas --> Details --> Patterns
corresponding with
Draw mode --> Detail mode --> Layout mode

Also:

Formulas + Outlines + Internal Paths = Details

Details + Passmarks + Joins + Labels + Grainlines = Patterns


#6

Hello,

Susan, I guess you are a native English speaker. Other English speakers could also give their opinion. I suggest the following experience:

If you put aside your knowledge about Valentina, and focus on your knowledge about “non-digital sewing”, e.g. imagine you look someone with significant practice of sewing (either as a passion, or professional use), while working on a new pattern design, and discuss with him/her in English:

  • how would he/she call the result of the work after tracing initial points/lines/marks on paper (including points/lines/marks that are not intended to appear on the end document)?
  • how would he/she call the result of the work after contouring the real cloth pieces?
  • how would he/she call the result of the work after placing the pieces on a large sheet, to get a printable pattern?

At this point, I would say the following wording could be closer to usual wording:

  • Draft (in French : Esquisse)
  • Pieces (in French : Pièces)
  • Layout (in French : Mise en page)

Using an intuitive wording seems important, in order to help new Valentina users feeling confident, and immediately comfortable with the tool. Even if there is a learning curve in order to make a pattern, users would be prone to insist if their first impression is positive.

Bye, Yann


#7

I was racking my brain for a better word for the first stage. “Model” is a candidate, or it would be except for the fact that in the fashion industry a model is a person. I think that “Draft” is pretty good. It conveys an element of drawing, but makes me think of a more professional type of drawing like a CAD or engineering drawing. It also works in its other meaning (draft/final).

That does free up the term “Pattern piece” being something that has all the finishing touches and markup applied to it and once printed is what you would cut out to give you a piece.

Those terms would have saved me some of my initial confusion. (Though I must admit I never stopped to read the manual - but who does?)

Is this just translation text as far as the codebase is concerned? (With a knock-on to existing documentation like the wiki.)

The other term that is slightly unintuitive is ‘increments’, but thats another topic :slight_smile:

Jason


#8

Sewing, measurement, and patternmaking terms are overloaded in every language.
We are in the position of having to solve this ancient dilemma.
Sorting this out will require starting somewhere, so perhaps we can start here:

Perhaps we should use the term ‘Piece’ to refer to each individual large object in Draw mode, Detail mode, and Layout mode.

Draw mode – canvas mode where we enter formulas to create points, lines, curves, and arcs.

  • Should we rename ‘Draw mode’ to ‘Draft mode’?
  • Is ‘Draft piece’ a good term for individual pieces in ‘Draw’ or ‘Draft’ mode?
  • Is ‘Valentina Draft file’ a better term for the .val file than ‘Valentina pattern file’? (Perhaps not, yet calling a Valentina *.val file a ‘pattern file’ collides with the common understanding that a pattern is a final printable/printed image or template intended for cutting fabric.)
  • Does anyone have other suggestions for changes to ‘Draw mode’ terms?

Detail mode – canvas mode where we add labels, grainlines, passmarks, internal path details, join Detail pieces together to create conglomerate Detail pieces, and select which Detail pieces should be included in the Layout image

  • Should we keep the term ‘Detail mode’ or rename it to something else?
  • Is ‘Detail piece’ a good term for individual pieces in Detail mode?
  • Is a ‘Pattern piece’ a ‘Detail piece’ which is selected to be included in the Layout image? If no then how do we name the pieces which are intended to be included in the final pattern image, and distinguish them from the Detail pieces which are not final pieces?
  • Is the ‘Pattern’ the set of all Detail pieces which have been selected for inclusion in the Layout image?
  • Does anyone have other suggestions for changes to ‘Detail mode’ terms?

Layout mode – canvas mode where we create the final output image

  • Is ‘Layout mode’ a good term?
  • Is ‘Layout piece’ or ‘Pattern piece’ a good term?
  • Is ‘Valentina pattern file’ a good term for the layout image after it has been saved/exported as a raster or vector image? If no then how do we distinguish between the *.val file (non printable) and the printable image of the pattern (png/eps/pdf/tiled_pdf/ svg/dxf)?
  • Does anyone have other suggestions for Layout mode terms?

Increments Table

  • Is ‘Increments’ a good term, or is ‘Variable’ more accurate?
  • Does anyone have other suggestions for changes to ‘Increments Table’ terms?

Does anyone Agree, Disagree, or have a totally different perspective?


#9

Does anyone like these terms:

  • Draft mode (renamed from Draw mode)
  • Detail mode
  • Pattern mode (renamed from Layout mode) Perhaps this is not ideal, but it gets us closer to the notion that the pattern does not yet exist in Draft mode or in Detail mode, but it becomes an entity in the final mode of construction when an image is created from selected finalized Detail pieces.

Okay does anyone Agree or disagree, and does anyone want to tell me that I don’t know what I’m talking about (yes, it’s possible :wink: ) or that this is just as confusing as the current terminology, or that there’s no need to change anything.


#10

I think the idea to find more appropriate terms is right. But to switch to new term we should be 100% percent sure it is better and more correct. Playing words is not the best time investment.

Don’t forget, english language is only part of community, translators correct any “mistakes” in terms how they want. So, not whole community see this as a problem.

The second thing we should keep in mind is investment in time to switch to new term. It is not only the code, it’s also the Wiki and localizations. There is thing we cannot fix. I am talking about video. See how many confusion people have after redesign. Some even found our new design worst than previous.:frowning_face:

Maybe this is loudly said, but we in position to create new terms which other will use. It is pretty obvious for me, because we create something new. And new things should have names. Parametric patterns was poorly represented in world of software. And taking all terms from paper patterns is not always right way. Such thing as variable doesn’t exist when you deal with paper. You see it as length or value. Probably named value will be even better name.

Long time ago i proposed to create a glossary. Place where we can keep definitions for all terms we use now. Probably it is time to return to this idea again.


#11

I have to agree with @dismine. As a program ‘whole’, it doesn’t really matter what you decide to name different sections. It’s like the chapters in a book. What you call them is your business. They are only titles that are as descriptive as possible. Many people will find other words to replace them with.But so much time and effort has already gone into these titles, that to change them would mean having to find every reference to them everywhere and I think that 6 or 7 years down the line is a little late for that.

As for the term ‘Increments’ vs ‘Variables’… An increment is the value with which one increases by on a fixed scale and as such, it has its place in pattern making.

A variable is quite the opposite. It is a value that is likely to change under certain conditions, which also has its place in pattern making.

If this question is related to the Tables of Variables under Measurements in the Menu in Valentina:

I would suggest changing the Increments title to Unique (or something similar) as I consider this to be increments AND variables that are unique to the pattern being created and not necessary to be included in the measurement file made with Tape.


#12

Hee-hee, I must have missed this post, but I have been thinking along the same lines and have actually created a section for this in the pdf that I’m busy with, although I haven’t put much into it yet. I’ll put more work into it.


#13

Perhaps I’m biased because I’ve spent the last few months writing the pdf, but I’d really love it if you leave these titles as they are :slight_smile:

(Especially because I’d like you & @dismine to work on getting the 3D going :heart_eyes: )


#14

The variable in programming is an element which value could be changed during the execution (in Valentina it is not possible). In computer terminology these are more like a constant or a parameter. I consider these as User Values.


#15

Variables is too fluid a term - especially as this is what the individual measurements are.

How about “Sizing/Sizes” .

In terms of the names for Drawing -> Detail -> Layout.

How about ‘Block’ -> ‘Pieces’ -> ‘Pattern’ ( Layout suggests the optimised version of a cutters table)


#16

IMO, at this point Valentina’s usability has two painpoints:

  • wording: terms are not always consistent with the underlying concept (e.g. “Seam allowance tool”, that relates to a more general concept that may be “workpiece”), and maybe too much terms are used (e.g. : use of “detail” term vs. “piece”)
  • hierarchy or feature organization: Valentina has a kind of implicit workflow, that does not comply with the way the UI can be understood at first glance. In other words, it is difficult to understand what shall be done in each mode. AFAIK (please tell if I missed something!), what is expected is that:
  1. user should load measures, that will be used as parameters in his pattern,
  2. user should draw points, lines, curves, etc. in Draw mode, and then select some to compose a detail/workpiece,
  3. user should add labels, passmarks, seam allowance, grainline, etc. in Detail mode
  4. user should choose export parameters in Layout mode

UI-wise, the workflow that is shown:

  1. skips measures selection (this one may be a hassle to solve, now that Tape is implemented as a separate tool),
  2. asks user to understand that “Drawing” tools are not used to Draw the final shape of the piece, but draft marks that are difficult to distinguish from marks that will be really printed/cut (same color/line patterns/naming)
  3. asks users to understand that the Detail is not defined in the Detail mode, but in Draw mode (they are said “You can’t use now the Detail mode. Please, create at least one workpiece.” eventhough they alrealdy created a “New pattern piece”.
  4. does not let so much things to do in layout mode.

I understand concerns about maintenance of existing documentation/tutorials, but my experience shows that it often valuable to simplify the tool and provide users with less documentation, because documentation is not needed (neither read) with a self-explicit tool.

I would tend to suggest a move toward this :

  • Sketch mode: name it “Sketch” or “Draft”, because these terms imply drawing, but drawing something that is not definitive. In this mode, show only sketching tools (points, lines…) in the left-side toolbar, and style points/lines/curves so that they are clearly “not definitive”, e.g. grey points, grey dotted lines/curves, grey lowercase labels.
  • Workpiece mode: allow access to this mode before a workpiece has been defined, and display only specific workpiece design tools in the toolbox, in order to ensure the place where Workpieces are defined is the Workpiece mode (mainly the equivalent of current “Seam allowance” content + “Piece path” tools). Once Points are labeled only when selected to compose a workpiece, so that the final layout does not show discontinuous labels like “A A2 A4 A6” labels when some draft points (here A3 and A5) were not selected in the workpiece path.
  • Layout mode: I do not know the tool good enough to have a relevant detailed opinion. :slight_smile:

Bye, Yann


#17

One question. Did you before proposing this count how much effort it will take to redesign and who will do this? You must understand that i made this design. Good or bad, but it works for me. It works for few i know. In my work i do something if like an idea, i need this or a user shows me real case where we definitely need this. Unfortunately i don’t have expertise to judge your proposal. I am developer and as most developers very bad in interfaces.:slight_smile:

Right now for me this disscussion looks like child play. What if name will be like this, what if i switch these parts and so on? What is the goal? Where is problem? What is wrong? Where is user cases that show that something is wrong?

Until these question will be answered i will not invest my time in redesign. But. As a maintainer i will merge changes. Proposing is easy, but if you go further you proved that you are seriously believe.


#18

[quote=“dismine, post:17, topic:1602, full:true”] One question. Did you before proposing this count how much effort it will take to redesign and who will do this?[/quote]

Gosh, no: I know this would be a significant amount of work. I always work with developers, and have sometimes developed, so I am plainly conscious of the amount of work that is implied by the least change. I also know the kind of suggestion I made exceeds by far my current karma in the project. And, except in case of a brilliant success in becoming a contributor, I may never get karma enough, neither (which is the real problem) become skilled enough in Qt/C++/Valentina guts to make it by myself. This is a characteristic of open-source governance: it is often a do-ocracy, where decisions are made by those who make the implementation. It is not comfortable for people who cannot develop, but I can understand that you are reluctant to spending time on changes that seem arbitrary. I just can’t imagine how much time you already spent on developing Valentina, so be sure I sincerely understand you.

Beside of this, I will try to contribute in a useful manner. For now, I can try to increase my development skills, pick some issues, and make a few pull requests (this is my personal challenge !). The other way I can contribute is by using my existing skills to improve the UI. The goal would be to increase/ease user adoption of Valentina, but I do not know whether growing the user community is a priority, or if your goal is to make a tool you can use for your personal purpose. The problem is that I feel it is not so easy to use for newcomers without significant investment and prealable experience with software. About user cases showing that something is wrong, it is difficult to prove a usability painpoint in an open-source context: my job usually implies organizing usability testing, with users trying to solve a scenario and me observing their problems, counting how much time it takes, etc. This way, you get concrete proofs of usability problems. But it seems out of reach in our context, so the other way is to build trust, so I can explain why I feel there is a problem from a usability point of view and try to convince you (and any other people that have karma enough to weigh on design decisions). Do you feel comfortable with such an approach?

So, coming back to wording issues: What is the goal? Ensuring names are consistent with underlying concepts, so that users that read a name in the UI immediately start building a good mental representation of the way Valentina works.

Where is problem? What is wrong? Where is user cases that show that something is wrong?

  • Several terms are used for same concept: “Detail/Workpiece/Pattern piece” and “Seam allowance tool” do relate to same concept. This can lead to confusing users.
  • There is an implicit workflow (make a draft -> define workpiece using the draft elements) that is strongly enforced by the tool (not possible to go to Details mode as long as no workpiece has been defined using Seam allowance tool), but absolutely no clue is given about how to proceed, in the tool.

Independently from the changes that would be needed to solve this, did I succeed in explaining the nature of the problem, and do you agree it can be considered as a problem to solve? If so, I can try to find ways to solve the problem without needing too much work? Or sticking with changes that I am able to do if you do not want to spend time on this. Up to you!


#19

I would mildly disagree with that. Although some wording is indeed might not be perfect, but by the end of the day it does not matter how you call an operator: it is the clarity of instruction of what the operation does and what steps need to be undertaken to get an operator to work are the most important, And this is majorly introduced in Valentina (maybe not as detailed as I would wish). I found Valentina only few weeks ago and it took me literally only 1 day to learn how to use Valentina and to make my first pattern, which included, formulas, variables, measurements, and even logical operators. I should probably add that I don’t have ANY experience in programming and had 0 experience in CAD-based programs before, I also don’t have much experience in pattern making - I think it says something about the user-friendliness of the program which is already in place.


#20

I like how concisely you put that. I’ll put my thoughts as answers to those questions.

  • What is the goal? To create a system that is

    • Straightforward to create
    • Easy to maintain
    • Provides a single source for all aspects of the project.
  • Where is the problem? Currently,

    • The terms for various parts of the project haven’t been decided on, which makes it confusing to discuss how to do something across versions, and especially hard to create tutorials.
    • Terms aren’t consistent within the program itself.
    • Editing the wiki/manual to stay current with program versions will only become more and more difficult and time-consuming.
  • What is wrong? (I assume) the dev (team?) started creating the software to accomplish the mission without fully mapping out the goal or how exactly to get there. This has inevitably caused a number of problems. THIS IS NOT CRITICISM!!! Most people moving forward into completely new territory do the same thing; you simply can’t know exactly how to get to somewhere when you aren’t completely sure where you want to go, and only those who have been on previous expeditions (…or have thought of seeking advice from those who have) know what to do. At least y’all have the humility to acknowledge that you aren’t perfect and seek help. Bravo.

  • Where is user cases that show that something is wrong? This thread alone demonstrates that there is confusion.


Here, then is the system I envision to make things work much more smoothly.

  • The wiki has a ‘Terms’ dictionary page where each term has a unique identifier (e.g. ‘Seam Allowance (tool)’ might have the ID ‘TERM0470’)
  • If multiple uses for a term come up, it can be defined as ‘term (context)’, as other wikis do, with each context having a unique ID. (e.g. ‘Draft (creating)’ might be ‘TERM0330’ while ‘Draft (section)’ might be ‘TERM0331’)
  • A routine runs on the wiki server that, upon an editing change, scans any changes and interactively updates the plaintext term (e.g. ‘seam allowance’) with a link to its entry in the terms dictionary. (e.g. ‘https://wiki.valentinaproject.org/wiki/terms:TERM0470’)

(The first reason for doing this is that this way, a term can be changed in the dictionary and every occurrence of that term in the wiki will automatically be changed to the new term.)

  • Whenever the software is run, it syncs a local dictionary with the main one.
  • Software uses the dictionary and definitions anywhere the terms are needed. For example, the string “seam allowance tool” becomes TERM0470+" tool", which then renders as seam allowance tool, or, if the term is changed later, workpiece tool.
  • Currently, hovering over something for two seconds causes the term for it to pop up. hovering for another three seconds would cause the definition for that term to pop up as well.

How does this make life better?

  • All terms and their definitions have a single source that synchronizes automatically, no matter which software version is installed. If a new term is introduced, previous versions simply won’t use it.
  • Any authorized user can edit the terms dictionary as needed, and all changes automatically propagate to all projects.
  • It no longer means that the developer(s) have to bear the weight of defining all terms and their contexts, though they can and should seed and/or refine the definitions.
  • All tutorials in the wiki will always be up-to-date in their terminology. (…and a small routine on other servers can easily update offsite tutorials/etc.)
  • Users would always have current definitions of terms available, even offline.
  • Localizations would (mostly) use the standard Mediawiki language dictionary method, making translations much easier.

I hope that this is clear. My brain still isn’t fully functional. It has been a looooong week.