I agree there have been many changes recently, but the deprecated components stay long enough for us to adapt.

And if you are customizing, you can keep your clone of the components, why depend on the officials?

Hi,

This is a strategy that keeps you in control, and adapt apps at your own pace to OutSystems UI changes:

1. Never reference OutSystems directly in your apps.
2. Always use a clone of OutSystems UI, name the clone with the version name in it.
3. This allows you to plan refactoring apps at a time, instead of needed to refactor a complete factory of apps at a time.

Regards,

Daniel

Thanks Nuno and Daniel

What you suggest is a way forward - we started the development when our scheme had very limited Application Objects, so this was a constraint. We did not expect OS's approach to retirement so we are where we are, in a difficult place.

We did not prepare ourselves defensively with the methods you suggest. Right now I am advised that we potentially have many weeks work to deal with the UI issues, although the impact on users is only slowly presenting itself.

Regards and thanks for your suggestions

Steven

Hi @SteveAdmin!

We are sorry to hear that you having problems with the migration to the new components.
We understand that all these changes we did during this year on OutSystems UI can be a bit disruptive and the migration to the new component is not always easy and can take some time.

From the beginning of this process, we tried to make it clear that we don’t have plans to remove the deprecated components because we know the impact of doing that and because the new components don’t necessarily have the same features as the deprecated component.

The decision of deprecating the components was exactly to mitigate the impact on existing applications, to release new versions of the components with a completely new architecture (avoiding known issues and not being constraint about them and finally have a real framework and not only a set of blocks), some with new UI and new features, without breaking the applications with the deprecated components, that’s also why we have a new stylesheet for the new components (to make sure customers can migrate at their own pace, without breaking their current implementation).

I assure you that you can take your time to migrate to the new components, the only impact of using the deprecated components is that we are not evolving them anymore, but they are still supported. If the new components don’t have a specific feature that the deprecated component has, give us that feedback, we are trying to act on that feedback fast to help with the migrations, you can even decide to keep the deprecated components (we don’t advice that, but will not break your apps). What we don’t advise is to clone the OS UI, that way your components will not be supported.

To help you with the migration, you can check our migration path pages.

Once again, we are sorry to hear that the update of the components was challenging. Feel free to contact us, we will be happy to help you!

Jéssica M.

Hello Jéssica,

Thank you for your reply and information provided. 

I see that you saying "can be a bit disruptive and the migration to the new component is not always easy and can take some time ". Our experience is that we need to spend several weeks to do this, even if spread over months, so impacting our annual targets.

Obviously we read "we don’t have plans to remove the deprecated components" as "It may happen...".  Can you clarify: over what time frame do your current plans run - 1 year, 3 years 5 years, 10 years?

We are very aware that you have in fact removed depreciated items in the past - for example v2.6.0 of OS UI was accompanied by an announcement that you had then removed 21 deprecated items (some of which impacted us). 

Ref the links you provided to migration path pages this seems a little sub-optimal. For example "Copy additional classes and styles of the button widget to the new one" but does not list what styles and classes that widget uses, therefore we have to spend additional time working out what they are and where. As well hoping we have not missed one...  (Please let us know if we have missed something there). There are 18 migration pathways listed of which we have to engage with 9. We are estimating 2-3 days per item. We have seen the "UI framework cheat sheet" but this not provide information on individual widgets.

I do have suggestions:

1. as far as I know we did not use any of the on-boarding support budget - could we now call on that budget for you to provide technical time to transition our apps over?

2. Hopefully 1 is possible - if not would you care to stand in our shoes and assign someone to spend a couple of hours trying to transition the apps to accommodate these deprecations, to fully understand the time required and complexity involved - there are many messy elements, for example, due to our customisations. Through this OS could better connect with an example of your customer's experience to inform your future strategy.

3. Is it possible you could improve the value of the migration pathways pages by listing the relevant styling and classes? . Perhaps a refined version of "UI framework cheat sheet"? Or kindly point to where we have missed the information we need? 

Best regards,

Steven

Hello Jéssica 

Thanks for your reply.

Every one who accesses the migration path pages will have to spend time to work out the missing information - how about the task to improve the quality of that page is brought forward (from the backlog) to the next weeks?

Your team already know what information is missing so it must be a simple edit - whereas we, and others, have to run through a guessing game. This would be super helpful - what do you think? 

This would give legs to the idea that OS is "sorry to see that the migration is causing you trouble" - by making it easier!  :-) 

Best regards

Steven

Hello Jéssica 

Am I in a position to mark this as "not solved"? I cannot see a way to do that.

I am ok if our communication is at an end but I do need an answer from "someone" else with regard to the work needed to add value to the migration pages, at least. Perhaps someone out there has already done this?

Steven

Thanks Daniel - good suggestions - I will do that - Steven