• State Suggested Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 431 subscribers
  • Views 1930 views
  • Users 0 members are here
Options
Related

Studio 2015 confusing Termbase viewer behaviour if a previous edit is not saved

Sian Cooper

Hi, I have found that when I selected to view (wanting possibly to edit) a term and its values, the entries showed the values for the previous term I had edited,  and it was not possible to get at the values for the term I was looking at. Screen shot below as an example, previous action carried out was to delete an invalid source term entry for 'efecto deletéreo'. Term I was looking at was Distrofia de Retina. Clicking on any visible value on the view screen did nothing. Noting that Edit is not available for the entries, but Save was, I wondered whether maybe I hadn't saved my previous edit (for 'efecto deletéreo'), so I tried the Save icon; that was indeed the case, it reverted to the entry for 'efecto deletéro', now saved; and I was able to reselect the entry I wanted. But it was most confusing.

Would be good if it didn't let  you get into this state, maybe it can check you save/discard edits before closing a previous entry screen?

Thanks
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0

    Hi Sian,

    You haven't closed the previous entry if you haven't either saved or rejected it. It's not possible to open another entry until you do. This is flagged up by Studio with the 'boxed effect' that shows the entry is active, as above, which is warning enough for me (unless of course you click the tab to another window in the same box it and then I guess a 'do you wish to save or cancel' message would be helpful but I imagine it would be pretty hard to program).

    If you try to view a second entry via the Term Recognition window, Studio will move to and highlight that term (or in larger termbases, something that is near what you have tried to view) in the Termbase viewer left hand list, whilst keeping the edit window to the right of that list open for the term that you edited but did not save or close. As we see above. I imagine this behaviour is not by design and is something to be avoided, I would say, as 'mixed messages' like this tend to cause software to freeze or crash. There is a limit to how much of the functionality of a big program like MultiTerm that you can squeeze into one tiny window of an even bigger program like Studio.

    Also, what we see in the above screenshot would not have happened if you had simply deleted the entry without opening it to edit. To do this, you just make sure it is highlighted on the left hand list then click the 4th icon at the top of the Termbase viewer window to delete it (the icon with the red cross rather than the yellow pen).

    No help I know but no-one else had answered you...
    All the best,
    Ali
  • 0 in reply to Alison Field
    Hi, Ali, thanks for coming back to me. On your last comment, if I have followed what you are saying (forgive me if I havn't) I don't want to delete the full term entry - what I had was 2 Spanish terms, in the same entry, which was wrong, and I just deleted one of them. As far as I could see, the only way to do that was to edit, open the invalid one and delete the text. Have I missed something? (I can have a play around, don't worry).

    On the more general discussion (I do enjoy a good discussion, I hope you do too) - I appreciate that 'avoidance' is best from the program's point of view, but I have to say I take things from the user's point of view as much as possible. Telling a user their behaviour is wrong for the program, rather than the program trying to help the user, goes against the grain of all my years of being a Business Analyst, sorry! I do, of course, realise that there are instances where it is just plain impossible to code in a fix/workaround to an issue - or is far more effort than a minor issue merits - but I still think usability issues like this should be addressed. It is what makes software great instead of good. I reckon if it is able to detect and revert to the previous unsaved entry when I select another term, there is an access-point where a 'you havn't saved your change' message could be slotted in. To my mind, that is basic error-catching, not trying to slot 'big' functionality in a small window.

    Admittedly, the present behaviour (which didn't cause a freeze and allowed the situation to be fixed) works - maybe an alternative solution is the current behaviour, but a helpful message explaining the user didn't save their last entry and do they want to now. That would clarify the confusing display that occurs.

    Of course, I also shouldn't be solutionising... slap my BA wrist!

    :) thanks again, Sian
Reply
  • 0 in reply to Alison Field
    Hi, Ali, thanks for coming back to me. On your last comment, if I have followed what you are saying (forgive me if I havn't) I don't want to delete the full term entry - what I had was 2 Spanish terms, in the same entry, which was wrong, and I just deleted one of them. As far as I could see, the only way to do that was to edit, open the invalid one and delete the text. Have I missed something? (I can have a play around, don't worry).

    On the more general discussion (I do enjoy a good discussion, I hope you do too) - I appreciate that 'avoidance' is best from the program's point of view, but I have to say I take things from the user's point of view as much as possible. Telling a user their behaviour is wrong for the program, rather than the program trying to help the user, goes against the grain of all my years of being a Business Analyst, sorry! I do, of course, realise that there are instances where it is just plain impossible to code in a fix/workaround to an issue - or is far more effort than a minor issue merits - but I still think usability issues like this should be addressed. It is what makes software great instead of good. I reckon if it is able to detect and revert to the previous unsaved entry when I select another term, there is an access-point where a 'you havn't saved your change' message could be slotted in. To my mind, that is basic error-catching, not trying to slot 'big' functionality in a small window.

    Admittedly, the present behaviour (which didn't cause a freeze and allowed the situation to be fixed) works - maybe an alternative solution is the current behaviour, but a helpful message explaining the user didn't save their last entry and do they want to now. That would clarify the confusing display that occurs.

    Of course, I also shouldn't be solutionising... slap my BA wrist!

    :) thanks again, Sian
Children
  • 0 in reply to Sian Cooper

    Hi Sian,

    No you haven't missed anything, the method you describe is correct. I misunderstood, thinking you wished to delete the whole entry. Now I have re-read what you wrote I can see that it was obvious... 'delete an invalid source term entry'. Oops! Fools rush in...

    Yes, I do enjoy a good discussion too ;-) and you're right, a program should always be designed around the user, which is part of what we beta testers are here for, to give the creators of this wonderful program as many user perspectives as possible so they can meet the broadest spectrum of user needs. I think that a helpful message advising why this or anything else is failing to happen would be great!

    I guessed it might be hard to program as it would seem an obvious feature to add otherwise. If enough users suggest it then I'm sure the developers will take it on board and do it if possible. There's a place for suggestions too, at http://ideas.sdl.com/

    Nothing wrong with solutionising, another very important facet of beta testing ;-))

    So, I don't want to detract from your post - it is a good suggestion. The odd helpful message here and there would not go amiss!

    Always nice to chat,
    Ali :)))