• Replies 4 replies
  • Subscribers 12 subscribers
  • Views 6312 views
  • Users 0 members are here
Options
Related

Override IType Property auto-label

neil.lindberg
Offline

After adding a property to an ItemType and tabbing from the property Name to the property Label there is the annoying behaviour I would like very much to override. I'd rather it stay blank than constantly needing to: Select all, delete, and finally enter a sensible label. I'm only critical of this annoyance because all the default labels are sensible, but whoever put together this auto-label didn't seem to take that into account.

For instance, the default label for "team_id" is simply "Team", and the default label for "release_date" is "Release Date". So, why would tab-to automatically copy the property name?

I'd like if tab to split on underscore and did a caps op on every word. Then, rather than constantly needing to delete the auto-label to enter one that conforms to the default look of out-the-box Innovator IType labels, it would actually be helpful!

This is a quick JS example, and I think if ANY auto-label this should be it:

```

// Change "release_date" property name to desired default-looking, "Release Date":

"release_date".split("_").map(x => x.charAt(0).toUpperCase() + x.substr(1,)).join(' ')

````

Parents

  • I like that you question things like that! I agree, most of the default properties don´t have pretty labels. I myself had simply accepted the fact that I had to change everything myself.

    Your idea might have one little problem. It might not work for language pack users, as the new label will probably be added to the language specific label field. It would be more pretty, if Innovator itself would build the ItemTypes with proper labels by default. It´s maybe already helps to fix the labels in the ItemType "ItemType".

  • Offline in reply to AngelaIp

    I'm finding it hard to accept this UI/UX altogether. As a coder I spend way too much time doing Admin tasks in this software and that makes the flow of things really stand out (as I can't wait to get back to coding).


    Honestly, while I do consider accessibility and language support on the front end - including dynamic labeling and any user-facing text, I have never considered language support when it comes to key names in a db.

    Are you saying that not all key names are in the Latin language chars? I thought they were. If they are, then the proposed idea works fine - and if the labels are to default to another language different from key names then they'd have to be manually entered anyway, wouldn't they?

    Side note - I think you'd like some of the CSS I added around this thing. Just some rotate on hover of pins, smaller search box that expands on focus (all pure CSS transition/transform with opacity/scale).
    You don't do contract work?

Reply
  • Offline in reply to AngelaIp

    I'm finding it hard to accept this UI/UX altogether. As a coder I spend way too much time doing Admin tasks in this software and that makes the flow of things really stand out (as I can't wait to get back to coding).


    Honestly, while I do consider accessibility and language support on the front end - including dynamic labeling and any user-facing text, I have never considered language support when it comes to key names in a db.

    Are you saying that not all key names are in the Latin language chars? I thought they were. If they are, then the proposed idea works fine - and if the labels are to default to another language different from key names then they'd have to be manually entered anyway, wouldn't they?

    Side note - I think you'd like some of the CSS I added around this thing. Just some rotate on hover of pins, smaller search box that expands on focus (all pure CSS transition/transform with opacity/scale).
    You don't do contract work?

Children
  • in reply to neil.lindberg

    When you use a language pack, you get additional properties in your database table. So you have the default "label" and separate properties like "label_de" or "label_fr". When I configure a property in Aras, the browser language defines which label_x is used when you add a property. But I get along with it.

    Your usability focus is really impressive and I agree that we admins have to spend a lot of time for tasks that could be done easier/faster. E.g. I hate when the LifeCycles editor destroy my beautiful layout when I click save and I have to repeat the process 3 times. But for myself, these kind of UI/UX improvements are my least concerns when seen in relation. Looking back I spent a lot of time just to make essentials work. There were known bugs producing wrong data. Not to mention security issues. And we know have Dynamic 3D Product Navigation, while at the same time Innovator has still huge trouble to handle multiple 2D images.

    Innovator is designed to be customized. This is what I like. But its´s also designed so it has to be customized. This is part of the business model cause most customers will not do this by themselves. Aras has the sole focus to growth (nothing negative about it!). But they mainly do it by expanding their platform at all costs, without spending much energy to address fundamental issues. Just look at the roadmaps of the last 3 years.

    This said, I always like to see other people improvements. But what I am really looking for are improvements to address the basic PLM tasks. I still cannot believe that there are people who say that the StructureBrowser is a well working compare tool that gives you all the info you need. From my POV Aras lost focus on basic PLM. Daily PLM work is not spinning around 3d models.