Why use Session variables for page-level search, filters, etc.?

Why use Session variables for page-level search, filters, etc.?

One of the patterns I've noticed (especially in IntelliWarp generated stuff) is the habit of using Session variables for the search fields in listings. In my experience, this causes a lot of issues, especially when the user opens the same page (or other pages with the same variables) up in separate tabs, or returns to the previous page.

What is the thinking behind this pattern? To me, this is something that I end up taking out manually and replacing it all the time. A customer of mine recently had issues because of it. Is there a good reason to use it that I don't see?

Hey Justin. 
Probably this question was directed at people from Outsystems, but I'd like to add my 5 cents as well.

I think it's a usability situation only. I can't really remember any issues I had with this default behavior, probably because I usually remove the session behavior like you do.

However, I can see the benefits in some specific applications. If you have a filtered list with a lot of data, and due to the amount of information or data nature you can't tell at a glance wich record you want to access, it must be very benefitial to be able to enter a record, (and if that's not what you wanted) click the link to go back to the list and try another one without having to apply those filters all over again.

It seems to me that, from a usability point of view, it would be a lot easier to just identify and put the relevant information in the list and provide the users with the ability to select the correct data at a glance. This renders those session based filters useless most of the time. (That is why you, I, and probably a lot more people remove that behavior)
Obviously, the IDE will never be able to identify that data for us so the next best thing would be the session based filters.
This is bad IMHO. It enables developers to be sort of lazy (if they wish), trusting that functionality & intelliwarp altogether, and with that develop applications that are below their full potential. And this is a topic I brought up in next step, in one of the birds of a feather tables:
  • Outsystems is such a great product, with so many functionalities aimed at simplifying the development process, it sometimes ends up making developers forget some important concepts and therefore overlook some situations. This is not an Outsystems problem, they do a great job with the product, it's a people problem... Of course good developers will always have their programming background and think of the correct solution on their own, but it's so easy to start using the IDE+Platform that everyone can start using it right away, so everyone can join the party. From a strategic point of view, if you're going to make it that simple to join, you have to add features that improve that capability so you can sell the product as "the simplest most powerfull thing on earth". If you want to allow just anyone to join you will have to deal with the trade-off of atracting every kind of developer, so you might as well make it simple to them and avoid recurrent errors.
Fortunatelly, usability is a hot topic (hotter everyday, and Outsystems seems well aware of it since it now includes usability tests in their project plan model) and situations like the session based filters might change soon, to a better patern inline with all the fuss around usability standards. Their usability teams are very good, I had the chance to talk with two of their leading usability guys and loved their insight (Gonçalo & Sara), so I trust people like them are providing feedback to the R&D team to improve paterns. :)

I totally agree with you Justin, and would also like to see someone else's opinion on that patern that I (like you) tip toe around. :)
Antonio -

Nice to know that I'm not the only one who takes it out! You are right that there is the case that you want to be able to click "Back" to return to the previous screen with the same settings. Outside of that, I don't know what else to use it for.

I also agree with what you said about the system being so good, it allows people to get lazy and make mistakes. A few other mistakes I see all the time:

* Relying too much on IntelliWarp
* When picking a value to set, taking the first (or only) item offered in the drop down list
* Session variables instead of page variables, as discussed
* Advanced Queries - These should be avoided at ALL COSTS because they are impossible to properly maintain! This is almost always a sign of someone new to the platform, and using an Advanced Query is their way of doing something familiar and comfortable, or because they have the SQL written somewhere else and copy/paste it. I've been using this system for 3 years and while I have often said, "maybe I need an Advanced Query?" I have never absolutely needed one.
* Leaving in the default error handling of catching an exception and dumping it to the screen with FeedbackMessage... this is about "worst practice" as you can get, since you never want to expose the kinds of technical details that this exposes (such as underlying table names) for both usability and security reasons

All of these (except for the Advanced Queries issue) stem from people copying what Service Studio does, and treating it as a "best practice" when really it is just a "default practice for the tool" that many humans would not choose on their own.



When there are some common filters (say a "project") along the application, it might be useful to have some filters in session variables. This way, when you navigate to a different page that also filters by the same "top level entity", it is already filled. Nevertheless there are also drawbacks (e.g.: not easy to bookmark the page). And as you say usability has a major role here - in the way the information arquitecture and application is created - if properly done, session vars shouldn't probably be used.