Expose a link to playpen in footer?

[ericberman]

Decided against exposing in the footer; I'll add an FAQ item instead.

[KayRJay]

I just discovered the Playpen features (thanks to GitHub). I located the Playpen page by following the link in the FAQ for merging flights, and noting the URL.

I understand the well-stated rationale for keeping the kind of features in the Playpen somewhat hidden. The FAQ is a good place to learn about them, I suppose. However, these "quasi-features" don't seem expose the user or the database to particular harm.

However, some of the features are likely going to be rather esoteric or of interest only to a few users. I'm curious why you chose to have a FAQ about (each of) them. That might actually give these features more prominence than you really want. (Or, perhaps instead of a separate FAQ for each feature, you intend to have one question to point to the Playpen: "Where can I try out possible new features of MyFlightBook"?)

Exposing such features from the Playpen page is cleaner than having the user add an extremely subtle parameter to the standard URL. I don't recall the particular (test) features you've previously (temporarily?) enabled by adding a parameter to the URL, but the Playpen could be used instead to enable/disable their use.

It's interesting to see the kinds of functionality you're playing with, and convenient to get to them from a footer link. Since it is easy enough to find the Playpen page as I did, putting a link in the footer doesn't seem a bad idea, unless I'm not seeing a risk to doing so.

[KayRJay]

Now I have it ... the hidden feature was for ALL/ANY/NOT for flight characteristics and for properties. This required the parameter "conj=1" to be added to the URL of a page with a search form. This feature could legitimately be added to the Playpen, where it could be enabled/disabled.

Eventually, based on usage (if you track that perhaps by analyzing the use of the URL?) such features could be promoted to standard features.

[ericberman]

Yeah, I wrestled with putting it in the footer. There's a tradeoff between how much prominence you give something and how much you need to support it. I'm going with the FAQ for now because I don't think (at this point) it needs the prominence that the footer would give it. The main work item here was to have a landing page - up until now, each of the playpen 7 tools stood alone and so I'd have to remember the URL and type it explicitly whenever I'd need one of the tools (except for the oAuth page; that's always been accessible from the developer page). Now I can just go to Playpen and then click on the link.

I don't have "conj=1" anywhere (at least not anymore) that I can find in the code. Did I have that briefly while developing the all/any/not stuff?

Anyhow, to your point about exposing such features in the Playpen vs. having URL parameters, these are kinda apples and oranges. The playpen has isolated functionality - the playpen page exists to provide a service that you can't do elsewhere on the site. The obscure parameters you can add to a URL, on the other hand, are tweaks to existing functionality - they make existing pages behave slightly differently. Usually, this is stuff that I use internally to pass information from one page to another. E.g., "night=yes" is used by the mobile apps (which support a "night mode") when displaying a page from the site, so that showing that page isn't a jarring bright transition at night. Or "naked=1" removes a lot of the navigation, which is again useful for the mobile apps when displaying an embedded page from the website, but is generally not needed (or even wanted) in a browser environment.

See https://myflightbook.com/logbook/Public/FAQ.aspx?q=41#41, by the way, for my list of various tips and tricks (including some URL parameters).

[KayRJay]

I understand the rationale. The question of how much prominence to give a feature is a tricky one. I can’t argue the merits of giving any of these features (except perhaps Day/Night) more visibility. That one isn’t in the FAQ (yet, is it?).

I added mention of all/any/not stuff in my comment.

I get the difference between linking to a page containing unique services vs. a tweak. Fair enough.

Re your “laughing” at my comment about finding the Playpen via the URL … yeah, that’s kinda funny. But now that I have the link, I’ve bookmarked it (and advertised it in Github! 😀). So, your “secret” is no longer secret.

One other reason to re-consider making the Playpen visible in the footer … it’s more work to write a FAQ answer than to add the link in the footer.

Thanks for the reminder re tips. Very helpful!

By the way, do you track usage of features mentioned in the Tips by analyzing the number of times certain pages have been visited (URLs and parameters used?). You could decide to promote some of the hidden features to first-class if there is significant usage. Are there any features whose usage has surprised you?

On Jan 4, 2020, at 11:47 AM, Eric Berman notifications@github.com wrote:

Yeah, I wrestled with putting it in the footer. There's a tradeoff between how much prominence you give something and how much you need to support it. I'm going with the FAQ for now because I don't think (at this point) it needs the prominence that the footer would give it. The main work item here was to have a landing page - up until now, each of the playpen 7 tools stood alone and so I'd have to remember the URL and type it explicitly whenever I'd need one of the tools (except for the oAuth page; that's always been accessible from the developer page). Now I can just go to Playpen and then click on the link.

I don't have "conj=1" anywhere (at least not anymore) that I can find in the code. Did I have that briefly while developing the all/any/not stuff?

Anyhow, to your point about exposing such features in the Playpen vs. having URL parameters, these are kinda apples and oranges. The playpen has isolated functionality - the playpen page exists to provide a service that you can't do elsewhere on the site. The obscure parameters you can add to a URL, on the other hand, are tweaks to existing functionality - they make existing pages behave slightly differently. Usually, this is stuff that I use internally to pass information from one page to another. E.g., "night=yes" is used by the mobile apps (which support a "night mode") when displaying a page from the site, so that showing that page isn't a jarring bright transition at night. Or "naked=1" removes a lot of the navigation, which is again useful for the mobile apps when displaying an embedded page from the website, but is generally not needed (or even wanted) in a browser environment.

See https://myflightbook.com/logbook/Public/FAQ.aspx?q=41#41 https://myflightbook.com/logbook/Public/FAQ.aspx?q=41#41, by the way, for my list of various tips and tricks (including some URL parameters).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/437?email_source=notifications&email_token=AEBRDEERXHFCAMYZFXDHASLQ4DKUXA5CNFSM4KBWOII2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIC5XYQ#issuecomment-570809314, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBRDEBLONTCN4BDA7665D3Q4DKUXANCNFSM4KBWOIIQ.

[ericberman]

I probably can track the usage, mostly haven't looked. That's one advantage of the URL hack - they show up distinctly in Google analytics. Some features have been promoted - e.g., I promoted page size (# of flights per page) a few months ago.

Mostly I go by the squeaky wheel theory: if enough people ask to address a scenario, that's my evidence that it's a scenario I should address. If it's a troubleshooting/corner case (like "dupesOnly" to find duplicate flights) - it generally makes more sense to bury it in the FAQ than to expose it, because until you need it it's just going to be confusing and clutter to explain it or show it to you, but at the point that you know you need to ask, you can find it. Others (like the various ways you can type into the paging box at the bottom of your flights) are just ways to unexpectedly delight (I hope!) people. But when enough people ask me about it, I promote it.

[KayRJay]

Well, as you know, some people are lazy or hesitant to ask for features (not me, obviously!). I'm actually surprised that you have received input on such features as page size after it first appeared in a hidden form. Good to know that happens occasionally.

It would take some time to do a real analysis of usage, of course. So, the squeaky wheel mechanism probably is best.