bundle the main Tickle html with the app so users don't have to download it themselves #15

Open
opened 2022-08-24 06:19:06 +00:00 by yagich · 2 comments
Owner

if Tickle isn't found in the server directory, the app should still work seamlessly. this can be facilitated by providing it bundled in the app, or by downloading it from somewhere.
it can then be placed in the chosen directory. when choosing a different directory and the new directory doesn't have Tickle (check for presence of an index.html file?), a dialog could pop up asking the user if they want to copy over the Tickle file (useful if it was modified by the user/is a different implementation) or if they want to use a new one, or to cancel the directory change operation.

if Tickle isn't found in the server directory, the app should still work seamlessly. this can be facilitated by providing it bundled in the app, or by downloading it from somewhere. it can then be placed in the chosen directory. when choosing a different directory and the new directory doesn't have Tickle (check for presence of an index.html file?), a dialog could pop up asking the user if they want to copy over the Tickle file (useful if it was modified by the user/is a different implementation) or if they want to use a new one, or to cancel the directory change operation.
yagich added the
enhancement
question
labels 2022-08-24 06:19:06 +00:00
Collaborator

I'm considering also the option of never having to show the user the html file or the list of files.

After all, they're only needed on the server. We could bundle them with the app, or the various templates, or download them from a repository, and the user may never have to know about them.

We can keep a list of directories that are tickled in a config file read by the app.

The plusses:

  • user's filesystem is untouched (at least in ways that they can perceive)

The minusses:

  • every UX step takes us further away from simplicity

This tension is expected and natural, but I didn't predict it'd rear its ugly head that early.

A third option would be to displace that complexity to the configuration: a checkbox for "write the html file to disk", which would "install" tickle in the directory.

check for presence of an index.html file

It's fickle, specially if we want to allow people to customize. We could have a meta-tag, but that starts to add even more difficult-to-explain convention. I'd rather we trust the user to be able to indicate to the app where their files are.

I'm considering also the option of never having to show the user the html file or the list of files. After all, they're only needed on the server. We could bundle them with the app, or the various templates, or download them from a repository, and the user may never have to know about them. We can keep a list of directories that are tickled in a config file read by the app. The plusses: - user's filesystem is untouched (at least in ways that they can perceive) The minusses: - every UX step takes us further away from simplicity This tension is expected and natural, but I didn't predict it'd rear its ugly head _that early_. A third option would be to displace that complexity to the configuration: a checkbox for "write the html file to disk", which would "install" tickle in the directory. > check for presence of an index.html file It's fickle, specially if we want to allow people to customize. We could have a meta-tag, but that starts to add even more difficult-to-explain convention. I'd rather we trust the user to be able to indicate to the app where their files are.
Author
Owner

I'm considering also the option of never having to show the user the html file or the list of files.

honestly, that was my first thought when writing this issue!

We can keep a list of directories that are tickled in a config file read by the app.

i'm not sure how this is related besides providing an easy way to switch between frequent directories?

This tension is expected and natural, but I didn't predict it'd rear its ugly head that early.

yes, that's why i didn't put my original thought into the issue. although, thinking about it more, maybe the app does not necessarily have a need to be as hackable as tickle itself? it depends on what we want the app to really be. is it a more or less full suite for writing and publishing, or is it an easy way to preview your site?

a config option to write the html (and files.txt) file to disk sounds like a good option, though comes with the question of whether it should be on by default :P

> I'm considering also the option of never having to show the user the html file or the list of files. honestly, that was my first thought when writing this issue! > We can keep a list of directories that are tickled in a config file read by the app. i'm not sure how this is related besides providing an easy way to switch between frequent directories? > This tension is expected and natural, but I didn't predict it'd rear its ugly head that early. yes, that's why i didn't put my original thought into the issue. although, thinking about it more, maybe the app does not necessarily have a need to be as hackable as tickle itself? it depends on what we want the app to really be. is it a more or less full suite for writing and publishing, or is it an easy way to preview your site? a config option to write the html (and files.txt) file to disk sounds like a good option, though comes with the question of whether it should be on by default :P
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: yagich/tickle-godot-frontend#15
No description provided.