Removal of the find feature in SS

Removal of the find feature in SS

  
Hello
 
I just upgraded to the latest version of the SS (9.0.0.36), and was surprised with the new find feature (Ctrl + F) . It seemed that it redirected to the Search Feature (Ctrl + G).
 
So I went to the release notes and discovered the "Find operations are now integrated with Omni-Search (#842672)"
 
Apparently I was right, but after some inspection I found out that it has missing some core features from the old find, namely the "Match case" and "Match all word". 
 
Was this intentional or an oversight? If it was intentional, what was the rationale behind it? Because both of them are useful (IMHO)
Hi Pedro,
There's a workaround: use Ctrl + R (Find and Replace) and leave Replace input empty.
There you can still use "Match case" and "Match whole word"
Hi Pedro,

Thanks for your feedback! We decided to move the Ctrl + F shortcut to the Search because we found that most of our users where using the Find do find elements that could be discovered by the Search, which would increase their productivity. As for the old Find we found that most of the developers didn't use those two options, "Match case" and "Match all word", exception made when they wanted to replace something. So we decided to improve the old Find mechanism so that users can replace text without doing two steps. 

Overall we are aiming to improve the overall productivity of our developers, and to increase the consistency of our tools.

Can you tell me if you use these options on a daily basis?


Thanks,
José Caldeira
Actually I was extremely happy with the previous way of doing things: Ctrl+F for Text searches, Ctrl+G for platform related searches
 
Though probably the most common use of the match cases could be the replace, I also use it to find specific code when refactoring something.

The question is why remove it? It has always been there, now it's gone, when the time comes that i really need it I need to find some trick that allows me to use it again (in this case the Ctrl+R, which didn't exist before and would most likely go unnoticed)
 
Another thing that is really obnoxious, it's the on hover and focus behaviour of this new Search, especially since it's near the Data tab, I've found myself writing in the wrong place just because I accidentally moved the mouse near the magnifying glass. Why the change from click pattern? There is no gain in it IMHO
José, you exemplify the problem that's been running through OutSystems lately, that you guys can somehow determine what "most of the users" do. The fact is that there are a lot of power users out there, that may do things differently from what you envision "most users" would do, and given the growing popularity of the platform, that means that "all users" - "most users" still equals a considerable amount of people. Especially in version 9.0.0.36, we've come across many small changes that are incredibly annoying (not to mention really breaking stuff).

Hi guys,


Again thanks for questioning our decisions, that's the way we can evolve the product and that helps us to make it better.


First of all let me clarify the process we have used to define if we should do this change or not, because I believe transparency is the best tool anyone can use. During this last year we have been performing lots of usability tests, on advanced developers and newcomers (being the latests our main focus). On these tests we have found some amazing insights, things like people going to the search and not noticing that they have to click on the magnifying glass, people searching for text on it, people searching for community content... among other things. With these insights in mind, we decided to check some data points that we have to see if these could represent common patterns, and in some cases we found that these were possible false positives, on other cases we found that these were possible issues, that could be affecting more users than we would like.


That said, you stand correct Kilian, there are power users for which change is harder because it impacts your daily work, I’m a developer and I know the impact these kind of changes have on my productivity (for example when I have to use a computer of a co-worker, I miss my shortcuts, tools…). We have been thinking on ways in which we can do these changes while minimizing the impact, because we believe that change is good and necessary but we don’t want to make your daily work harder, actually we want to improve everyone's productivity. However, we still haven’t found a good way to do this because of possible issues on our training materials, and other excuses that at the end of the day I believe you would understand, but that you would also say: “You shouldn’t use that as an excuse, and you should allow us to…”. It’s just a matter of cost/benefit, and again I stand on your side that we need to be more careful, and to learn with these small annoyances.


By the way, could you share some of your latests concerns? We may not fix them now, but we would like to avoid them on the future. As you say, the number of developers that uses the platform is rapidly increasing, and we want to empower them with the best options we have, that’s why we focus our tests on the newcomers, but one of the best ways to empower these guys is by having guru’s on our technology sharing your knowledge, on the forums, on stackoverflow… and for that we cannot “annoy” you =)


That’s why we want to learn with you, the community, and that’s why we have things like the Ideas zone (by the way we also had an idea to merge the find and the omni-search).


Sorry for the huge post, my biggest ever, but I couldn’t bypass the opportunity to say thank you all for these kind of comments/critics, that help us improve as a company and to improve the product we develop. I also need to say sorry for the annoyances, but hopefully at the end of the day each version we deploy is better than the previous and you get to be more productive.

Cheers,
José Caldeira

Hi José,

As for my concerns, if you check with the support guys and mention my name, I'm sure they'll start running and screaming :). I report issues, both bugs and usability stuff, almost on a daily basis, so there's a lot of valuable information there :).

As for my biggest concern, it's version 9.0.0.36 in it's entirety. Not only does it have user interface issues like the Ctrl-F being changed, but it introduces a host of new stuff that I was expecting not before the Amsterdam beta (many of the stuff fixed in .36 like Unicode support was announced for the beta programme). It even seems to have broken something completely, viz. the way records and record lists are treated. For example, we seem to be unable to even create a variable of type Record, containing multiple records (needed for example for the output of an Advanced Query). There's also a lot of minor glitches, like when you open the expression editor and it only displays the last line by default, or the fact that the "clear" icon is missing from the search field in the multi language dialog, or that string input in the property pane is broken, or that recognized tokens in the property pane input aren't capitalized until loss of focus, or that the action tree sometimes "locks up", or that suddenly all of our web screens have a grey background i/o a white one, or that the tabs now have extra space above them, eating up useless screen real estate. These are all regressions from .23, which we now have downgraded to.

In general, version 9 felt like an experimental release with lots of issues (the aggregate editor is still partially useless for us because of it not showing the full table names, not to mention that at the very last stages of the beta programme, you removed simple queries, and we all know how well that went with the old-time users), but with 9.0.0.36 I really wonder whether you guys have any quality control in place (yeah, I know you do, but come-on, I caught most of the issues mentioned above in the span of a couple of hours).
Thank you for your words José. We will continue to give feedback because we care.

Kilian, regarding one of your mentioned glitches, of being unable to create a variable of type Record, I just replied to another member on this post: http://www.outsystems.com/forums/discussion/14270/cant-have-variable-of-record-list-any-more/

But it does feel like there could have been a smoother experience on the new versions, which as Killian said have issues that are detected after a couple of hours of use... The EditableTable in particular is a real work in progress...
 I agree with most of Kilian's suggestions/reports
 
Yesterday I spent about 4 hours trying to fix an issue that only existed due to the new method to create complex variables (Record of Entity is different from of type Entity, when using extensions like XML Records to output a complex hierarchical structure, we have to find the correct way for the object to be interpreted, Record List of is also different from List of, etc.)
 
Other thing I've noticed, the popups changed drastically, assuming that you are using a Form inside a popup, the popup doesn't have the correct behaviour when it resizes. We must force a width while calling the popup (unsized popup looks like the image below), but then how it will look when we use the app in smartphones/tablets and have the fixed width come up?
Didn't finished :-)

The removal of sinple queries is also an issue, at the moment I don't use Aggregates, I rather code the advanced queries myself then use Aggregates. I've really haven't seen much improvement in aggregates over simple queries, other then the quick visualization of the data. The best option would be to have both of them available and let the user choose which he'd like to use, not just force one option...
An issue I had with 9.0.0.36 which made me revert to the previous version was that in the eSpace editor I was doing a lot of cut and pasting and it was completly losing position. On a couple of occasions it (unknowingly to me) deleted the wrong elements and I had to revert to a previous version. Primarily I just lost the r-click options completely.

The relative awkwardness of creating Record's was also an issue which I don't now have having reverted to 9.0.0.23.
I thought the copy/paste not keeping position was a v9 thing, not specifically .36? Another thing that comes to mind that annoyed the hell out of me is that comments now have reversed attraction points for linking and moving. Reversed compared to previous versions, but also reversed compared to other canvas widgets. OutSystems explained to me that this was intentional, but never disclosed the rational...
I see the changes in .36 the same way I saw the upgrade to Office 2007 and the "Ribbon":

* New users will have an easier time.

* Power users have a LOT of painful re-learning.

It took me a bit of time to figure out how to edit Record types in .36. Once I did understand... well, this particular one still isn't good.

CTRL+F compared to CTRL+G and CTRL+R? I spent a few days very confused, but once I found CTRL+R I kept moving.

I think the *biggest* issue is that these changes are not being properly introduced. I thought the original CTRL+F behavior was simply gone, it was pure luck that I found CTRL+R. As someone who has been using OutSystems since version 4... that's a big, unexpected change. While CTRL+G is the behavior I want probably 90% of the time, which makes it the right behavior for CTRL+F *for a new user* it was confusing for me.

Another good example are the lists of primatives introduced in 9. I don't think I knew anything about these until I accidentally started creating them, and I am still learning new things about them (like the ability to make a List of Identifiers).

Again... this is a GREAT feature but it needed a proper introduction.

J.Ja
Kilian Hekhuis wrote:
I thought the copy/paste not keeping position was a v9 thing, not specifically .36? Another thing that comes to mind that annoyed the hell out of me is that comments now have reversed attraction points for linking and moving. Reversed compared to previous versions, but also reversed compared to other canvas widgets. OutSystems explained to me that this was intentional, but never disclosed the rational...
 I never had (and don't now have having gone back to .23) an issue with cut and paste and losing context before using .36) 
 
Justin, you are totally right. In the past we used inline tutorials for that, but they weren't effective. On big launches we do a big buzz around everything. I risk to say that the biggest problem was the fact that this is the biggest launch we do on a "normal" release, I don't recall any release with more improvements =)
 
So... yes we also need to improve and we appreciate your feedback, although we go on weekend with the feeling that we, the R&D team, could have done things better. On the bright side we are proud to see you all move so fast into new versions, because that also means that you care about the work we are doing over here.
 
This is how I see things... but I may be wrong.
 
 
Cheers,
José Caldeira
Hi Killian,

The change on the comments was a side effect of the ability to have link urls inside comments now. The inside of the comments needed to be made clickable for the links to work.

The links were a important change since in our usability tests no users (even power users with years of experience) ever tried to search for help or use the F1 keys. So now when new flows are automatically created with a short explanation and a link to the documentation.
An example of this is when using the REST OnBeforeRequest and OnAfterRequest callbacks (expecially he Advanced ones). These are for advanced usages, but power users when faced with them for the first time were just getting stuck.

So we decided to add the links there and had to compromise on having a little worse experience on the comment arrows to have a huge improvement on user experience when using advanced features that required explanation.

Regards,
João Rosado
Jose -

To be fair... I think .36 is a great release overall. It's fixed a lot of stablity issues, the entire team has noticed a difference in it. The changes to aggregates are very welcome. I see the direction this is going in. Just need to find a way to make it a bit easier for us long-term users to not get confused or miss new features. :)

J.Ja
I tend to agree with Pedro..

Pedro Coelho wrote:
The best option would be to have both of them available and let the user choose which he'd like to use, not just force one option...
 Although he was referring to aggragates vs simple queries, I think the premise applies to the OP's concern as well.

I can understand making decisions on the basis of research, but I feel that there are certain things that should not be forced onto developers without options. The IDE usabilty is one major one. Options is what makes a good IDE good, and a great IDE great. While having too many options can be daunting for a new user, if they weren't allowed, no one would use software like Eclipse or Visual Studio. Having defaults is fine, but if I would like to use Ctrl+H (typical for many applications) for Find and Replace vs Ctr+R for example, I think I as the developer should still maintain the ability to choose that.
 
I feel customizability is definitely something sorely lacking in SS, and while still obviously usable, having that ability could greatly enhance the development experience. Even something as silly as being able to change the default white background of the canvas to a custom or even pre-chosen alternate color, or reordering the toolbox based on personal preference would give a feel of personalization to the IDE.

Maybe I veered off topic a bit, but I think the foundation is still there... curse of a rambling mind :)
João Rosado wrote:
The change on the comments was a side effect of the ability to have link urls inside comments now. The inside of the comments needed to be made clickable for the links to work. (...)

So we decided to add the links there and had to compromise on having a little worse experience on the comment arrows to have a huge improvement on user experience when using advanced features that required explanation.
Well, this is again an example of the OutSystems Overlords deciding what is best for the plebs using their product, without taking power users into account. Sure, it's nice that novice users get explained what's going on in wizard-created flows, but it is explained nowhere, not even described anywhere, it's just something that the Gods deemed appropriate from one day to the other. And that is simply not ok. And the experience isn't a "little worse", it's really a huge pain since I need to almost always link a comment to a specific canvas widget, and rarely do I need to move them; and given that the target area for having a linking arrow is much smaller now, the primary action is made more difficult. This apart from the fact that it is of course perfectly possible to make the inside of a comment clickable and retain the old move/link arrow functionality, you just chose the technically easiest way out. Double bad.

Justin James wrote:
To be fair... I think .36 is a great release overall. It's fixed a lot of stablity issues, the entire team has noticed a difference in it. The changes to aggregates are very welcome. I see the direction this is going in. Just need to find a way to make it a bit easier for us long-term users to not get confused or miss new features.
Although we have noticed .36 is slightly more stable in some respects, it is less so in others. We've had frequent lock-ups, and the strange action tree no longer responding properly. The changes to aggregates are indeed welcome, but the biggest problem, the fact that with longer table names it's not possible to see what tables are joined (unless looking at the join condition) is still not solved. This all combined with the fact that it is (almost?) impossible to define variables of type Record with multiple entities made our team decide to downgrade to .23.
And another thing we really resent, and I just encountered again: merging. Though the idea id nice, the way the new merging functionality works is completely incompatible with the way we manage our OTAP environment. Since it isn't possible anymore to uncheck everything (by unchecking the top level), we need to manually uncheck sometimes dozens of changes, with the risk that we just happen to forget one. We've screwed up a couple of times, and needed to explain to the business that's it's the way the new platform works...
Kilian,
I wasn't aware of that merge change... I am using an older version on my day to day and never tried a merge on the new platform version. I went to check it on my personal environment just now... Terrible and very error prone.

PS: By the way - OTAP? "O" stands for the dutch Ontwikkeling, meaning Development?
Oh, yeah, I'm so used to only using acronyms, and them being predominantly English, that I totally forgot this is a Dutch one :). It's DTAP (Development, Test, Acceptance, Production) in English.
We've been using the new merge "merge and publish" feature with zero errors in a 5 person team. We absolutely love it. Only problem we have is that it is slower than doing it manually. I think there's some room for improvement in the comparison algorithm.

J.Ja
Putting aside specific issues, in a broader perspective I would end my note, asking for OutSystems to consider these 2 suggestions:
1. Try to keep options previously available. Evolution and new features are great, but why reduce possibilities? (eg: Merge - not being able to select top level)
2. Document changes, as small as they might look. (eg: shortcut for find and replace)

Cheers
Justin,

You probably use the merge feature in case multiple team members are working on the same eSpace? We use it to merge specific changes from the dev environment to the testing environment, e.g. when needing to solve an issue found during user testing. The eSpaces can be modified already b/o changes in the new sprint, and we only want to merge the small changes back to the test version. Pre version 9 we could just deselect all, then select the right changes. Now we usually do it manually, which is more error prone.
Killian -

Yes, that's how we use it. I can see why the new system would be a problem in your case.

J.Ja
Tiago Neves wrote:
I wasn't aware of that merge change... I am using an older version on my day to day and never tried a merge on the new platform version. I went to check it on my personal environment just now... Terrible and very error prone.
Hi Tiago,
can you elaborate you experience with the merge? What was your merge scenario? Are you doing parallel development? 
Kilian Hekhuis wrote:
Justin,

You probably use the merge feature in case multiple team members are working on the same eSpace? We use it to merge specific changes from the dev environment to the testing environment, e.g. when needing to solve an issue found during user testing. The eSpaces can be modified already b/o changes in the new sprint, and we only want to merge the small changes back to the test version. Pre version 9 we could just deselect all, then select the right changes. Now we usually do it manually, which is more error prone.
 Hi Kilian,

I'm sorry your experience with merge in your scenario is not the one you expected. I'm not sure I understand your exact scenario in order to fix it. Can you send an example to lucio.ferrao@outsystems.com with the real modules and what you were trying to merge?

Thanks

Hi Lúcio,
Indeed, parallel development is often the case. Your comparison is working great and most of the times there's nothing or not much to change.
But when a change is needed in the selection of what is going to be merged I just think that the previous option of ticking a top level was very helpful as I could either select/unselect a whole web screen or web block - or unselect everything and just go to a specific element which I know is what I want to get. Now, to achieve that, I will have to go through every action and that can lead to an error much more easily than previously.
Merge is working great, but why taking that option away?
Tiago Neves wrote:
Hi Lúcio,
Indeed, parallel development is often the case. Your comparison is working great and most of the times there's nothing or not much to change.
But when a change is needed in the selection of what is going to be merged I just think that the previous option of ticking a top level was very helpful as I could either select/unselect a whole web screen or web block - or unselect everything and just go to a specific element which I know is what I want to get. Now, to achieve that, I will have to go through every action and that can lead to an error much more easily than previously.
Merge is working great, but why taking that option away?
When doing 3 way merge, selecting all the children was not the correct default as it would lead to lost code. Still, if you have a relevant scenario that should be simpler, let me know via email (lucio.ferrao@outsystems.com). If it makes sense we will fix it the product.

Lúcio,
Currently, in the project I'm on, we are not yet using platform 9. It will probably occur in 1 or 2 months.
However, a suggestion is that you could do like in the Add/Remove references, where we have the option to show in use or show all. We could have the same with "show top-level" in the merge.

I can say that it's an option we use before platform 9. Like we also use simple queries yet. But I do favor your approach of "forcing" users to the new features, like you did when you took out simple queries to introduce aggregates. Sometimes that's the way to go, the alternative is to have a transition phase were both coexist.

I will get in touch however if faced with difficulties on platform 9 merge.
This post went somewhere off topic in between and we discussed the change in Merge.
I've noticed that now we can select top-level again (Screens and eSpaces). I made a separate post with print screen: http://www.outsystems.com/forums/discussion/14950/merge-allows-top-level-selection-again/
Again... this is a GREAT feature but it needed a proper introduction.