With Sao it is very simple to share a link to a form or list view but the URL can be very large (+500 characters is not unusual).
It would be great if Sao could create a shorter link on user demand. Maybe we could add a button in Sao, when web_shortener is installed that creates such a link and offers it to the user.
That would be similar to what Google Maps does.
Opinions?
I can not find example of so long URL.
Why? When is it long URL a problem?
I dislike link client to specific module and web_shortener was not design to be a general shortener.
A shorter string is simply easier to manage. Specially in smaller interfaces or when sharing it using Whatsapp or similar services.
I’ve found myself using such a feature for sharing a link to Google Maps via e-mail, too because the e-mail is more compact, easier to write and easier to read.
Here’s an example:
You can reproduce it by going to the “Products” link from the list locations:
+1
About URL shortening:
Some system messages, like SMS, the number of characters is limited.
I do not understand. Copy/Paste was never more difficult with the length of the content.
Most client can support to shorten automatically links.
It is not forbidden to use a shortener.
I think the track to follow is to try not to encode parameters. I guess the browse should support it. Also we could try to reduce the size of JSON object like date/datetime/time/timedelta/Decimal/bytes to use shorter parameters (but stay backward compatible for decoding).
After some tests, we can not avoid to encode the parameters. Indeed the main issue is that we use JSON as format and it requires to replace all the , by %2C and : by %3A which are used in Array and Object.
So for me, the best would be to replace the JSON by another format more user-friendly to URI. (JSON is a bad idea for URLs).
I found two options for now:
We could probably implement a backward compatibility behavior in both clients by testing the first char before decoding.
Another point against shortened URL by default is that when the user paste the URL in an existing connected sao, it will trigger a reload of the full page. But when it is the full URL, only the parameters change and it does not need to reload the page.
Rison looks quite beautiful to me and I think it would be a good change for encoding URLs.
But I understand it could be implemented, even if instead of using the web_shortener was something more integrated into the core, isn’t it?
I understand that Rison is a good improvement over what we have now, however that will not prevent very large URLs, and I think the shortener can provide users a better experience.
For me, it will not provide any features compare to the current. Indeed as I said it will remove existing feature by loading a new page when it is not necessary.
Well a better format + a shorter PYSON will reduce a lot the URLs. The example above could probably be reduced by a factor of at least 5.
I do not think. It breaks some feature. And it obfuscates the target of the URL.
More over I do not see any proposal on how it will work? Will it create a new URL each time a user opens a tab?
Copy/paste will usually be simple (although I guess it may need triple-click in some browsers or the user may not be sure all the text was selected because not all of it fits in the URL widget) but when received in the Whatsapp application, you get a large link instead something smaller.
Using shortened links is something that is not required, so we can always argue that the user has other alternatives and that is true. But we’re talking about user comfort here.
My opinion is that user will feel more comfortable having a “share” button that creates a shortened link and even copies it to the clipboard (as Google Drive, does, for example). At least that is my preference as a user.
It will not remove any features. For me, the existing URL format (or the proposed Rison one) should work as they currently do.
My idea was just to add a “Share” button (similar to what GTK client already does) that when clicked, sao would create a shortened link for the user pointing to the current URL.