Food for thought on "projects", the sidebar and user experience

[Rasmus Andersson]

See »A better user experience when working on "projects"« at
https://github.com/rsms/kod/wiki/Get-busy

--
Rasmus Andersson

[Zach LeBar]

Very nice writeup Rasmus. Looking at the milestones at the end: I'm not sure if the first is possible. Now, I'm no Obj-C whizz, but I'm pretty sure that you need something to store what the user's preference of structure is one a project-by-project basis. Like you mentioned, for a PHP dev, a file system tree works, but for someone else working with a framework, it doesn't.

What kind of jumped to mind when reading this is that it seems like something that changes depending on what language/framework you're using. Wouldn't plugins be the ideal solution here? If we look at the sidebar design proposed earlier, one that allows for different representations of different data, then a plugin could change how that looks and what's displayed there.

- Zach LeBar

> --
> You received this message because you are subscribed to the Google
> Groups "Kod.app" group. To unsubscribe from this group, send email to
> kod-app+u...@googlegroups.com (More info at http://groups.google.com/group/kod-app)

[Rasmus Andersson]

On Fri, Jan 7, 2011 at 19:24, Zach LeBar <zach...@gmail.com> wrote:
> Very nice writeup Rasmus. Looking at the milestones at the end: I'm not sure if the first is possible. Now, I'm no Obj-C whizz, but I'm pretty sure that you need something to store what the user's preference of structure is one a project-by-project basis. Like you mentioned, for a PHP dev, a file system tree works, but for someone else working with a framework, it doesn't.

Writing "project description files" is not an option I'm afraid. Some
opt-in-to-use plugin might do it, but not by default. Many people (me
included) hate when programs mess with their file system w/o
explicitly being told to do so.

There are a lot of ways you can accomplish the first "milestone" w/o
having to write any files to a project's directory. For instance, you
could utilize xattrs to store tags e.g.
"se.hunch.kod.tags=project:project1,project:project2" or you could use
Spotlight metadata for storage. Or you could manage a shared database
in ~/Library/Caches/se.hunch.kod or ~/Library/Application Support/Kod.
Or you could let the state be somewhat transient and not persist
between session. Or you could do like Chrome and Firefox where the
current application state is archived and unarchived from disk (open a
bunch of web pages in Chrome, hit Cmd+Q, start Chrome and you'll have
everything back in place).

>
> What kind of jumped to mind when reading this is that it seems like something that changes depending on what language/framework you're using. Wouldn't plugins be the ideal solution here? If we look at the sidebar design proposed earlier, one that allows for different representations of different data, then a plugin could change how that looks and what's displayed there.

Yeah, maybe plugins/extensions would be a solution. But currently they
would need to be compiled Cocoa shared libraries and extensive work
would be needed in kod-core to allow plugins the full flexibility, I
think.

I'm opening this for discussion as there are a lot of ideas and no
real solid solution yet.

>
> - Zach LeBar
>
> On Jan 7, 2011, at 12:02 PM, Rasmus Andersson <ras...@notion.se> wrote:
>
>> See »A better user experience when working on "projects"« at
>> https://github.com/rsms/kod/wiki/Get-busy
>>
>> --
>> Rasmus Andersson
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Kod.app" group. To unsubscribe from this group, send email to
>> kod-app+u...@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Kod.app" group. To unsubscribe from this group, send email to
> kod-app+u...@googlegroups.com (More info at http://groups.google.com/group/kod-app)
>

--
Rasmus Andersson

[Alan Danziger]

The big problem with Spotlight or even a users' cache/App Support, is these aren't shared to other computers - I do most of my development on 2-3 different systems.

A solution to this problem might be to allow export/import of the configuration, within Kod.  Then I can take my "perfectly configured" machine, export the config, bring it along with my source, and import that on the new machine...  It's a manual process, which isn't ideal, but it's probably a one-time thing.

[Bryan J Swift]

Alternatively you could move that Application Support folder into your Dropbox folder and symlink it on each machine. Magic synchronization between machines for app support files.

On Friday, January 7, 2011 at 4:49 PM, Alan Danziger wrote:

The big problem with Spotlight or even a users' cache/App Support, is these aren't shared to other computers - I do most of my development on 2-3 different systems.

A solution to this problem might be to allow export/import of the configuration, within Kod.  Then I can take my "perfectly configured" machine, export the config, bring it along with my source, and import that on the new machine...  It's a manual process, which isn't ideal, but it's probably a one-time thing.

--

[Agos]

On Friday, January 7, 2011 8:57:21 PM UTC+1, rsms wrote:

Writing "project description files" is not an option I'm afraid. Some
opt-in-to-use plugin might do it, but not by default. Many people (me
included) hate when programs mess with their file system w/o
explicitly being told to do so.

There are a lot of ways you can accomplish the first "milestone" w/o
having to write any files to a project's directory. For instance, you
could utilize xattrs to store tags e.g.
"se.hunch.kod.tags=project:project1,project:project2" or you could use
Spotlight metadata for storage. Or you could manage a shared database
in ~/Library/Caches/se.hunch.kod or ~/Library/Application Support/Kod.
Or you could let the state be somewhat transient and not persist
between session. Or you could do like Chrome and Firefox where the
current application state is archived and unarchived from disk (open a
bunch of web pages in Chrome, hit Cmd+Q, start Chrome and you'll have
everything back in place).

The “project file” approach, while the most common, has its limitations: sometimes you don't want an additional file, and sometimes you don't know where to put it (in the root directory for the project? what if you are working on two directories that are not on the same drive? etc). But in my opinion a project file is one of the best option out there. It lets you refer to a project by name, you can easily delete it, etc.

xattrs and spotlight metadata are simply not made for this, I feel it'd be stretching them beyond their intended use. Plus, neither of those fits well with the use case of any metadata regarding more than one file (groups, etc.).

A shared database has the huge disadvantage of not being portable. BUT we could just decide that it's ok: you choose which project you want to work on, completely oblivious of where that info is stored (maybe a “projects” window? ugh, not liking it but not seeing alternatives now), and then work without ever worrying where your metadata is (kinda like the iphoto/itunes library metaphor)

[pjv]

i agree that programs messing with my filesystem without my telling them to is beyond annoying.

at the same time, i really like the idea of having a human-editable, plain-text, VERSIONABLE project/sidebar settings document that IF I CHOOSE TO CREATE IT can live in my project's directory tree somewhere (or wherever i put it).

in this respect, i like very much one aspect of how textmate does it. you can have an ad-hoc, filesystem-based "project" without any kind of persistent file by just opening up a folder in the sidebar (similar to the support for same that kod now has), and you can also choose to make it persistent in a file that you decide what to call and where it goes. i personally don't mind this when i choose where it goes.

although we are in another thread now, i really like the idea that someone put forward about how to structure such a file and the kind of different objects that could be represented in it based on a URI scheme.

[Rasmus Andersson]

On Tue, Jan 11, 2011 at 21:46, pjv <volk...@gmail.com> wrote:
> i agree that programs messing with my filesystem without my telling them to
> is beyond annoying.
> at the same time, i really like the idea of having a human-editable,
> plain-text, VERSIONABLE project/sidebar settings document that IF I CHOOSE
> TO CREATE IT can live in my project's directory tree somewhere (or wherever
> i put it).

Sounds good to me. Could be a two-step selection:

1. An opt-in action "Save project file as..."
2. A persistent boolean setting "Automatically create project files"

And then we store the project file in YAML (or JSON).

> in this respect, i like very much one aspect of how textmate does it. you
> can have an ad-hoc, filesystem-based "project" without any kind of
> persistent file by just opening up a folder in the sidebar (similar to the
> support for same that kod now has), and you can also choose to make it
> persistent in a file that you decide what to call and where it goes. i
> personally don't mind this when i choose where it goes.
> although we are in another thread now, i really like the idea that someone
> put forward about how to structure such a file and the kind of different
> objects that could be represented in it based on a URI scheme.
>

[Stephan Müller]

> 1. An opt-in action "Save project file as..."
> 2. A persistent boolean setting "Automatically create project files"

Thats about exactly what I had in mind. However, although I really
feel like we need to be able to save project files, I never use them
on TextMate, although they are available. The second point sounds like
a good workaround to this, but I'm a little afraid it will pollute my
file system too much. A solution might be to don't create project
files instantly, but only when you do some actual reconfiguration
inside the sidebar (adding additional files etc.).

There are some more problems this approach doesn't solve yet. I made
the following observations:

* Users want to have a workspace with all the files they need at their
fingertips.
* If users need to adjust their workspace to optimize their workflow,
they want to reuse the adjustments.
* Users don't want to explicitly create project files, name them or
safe them all the time.
* Users don't want Kod to mess with their file system.

TextMate has a neat feature to solve most of those problems: The "Open
Recent" menu contains not only files, but also folders. This could be
extended to also save project configuration (open tabs, sidebar item
arrangement etc.). Users won't be forced to create a project file
before leaving Kod. If they want they still can create one later.

Safari also solves some of those problems by its option "Reopen All
windows from Last Session". This feature would make it a lot easier to
resume work after crash or after the system needed a restart.

My proposal to handle projects within Kod:

* Add a "Reopen All windows from Last Session" option.
* Renaming "Open recent" to "Recent Files", and adding "Recent
Projects" which contains all the windows as soon as they contain more
than one file (and therefore become projects).
* The temporary projects listed in "Recent Projects" are updated
automatically, so they always represent the current project
configuration.
* Projects can be "saved as" to a file, and saved again, to update the
saved project configuration.

There could be a new "Recent Project" created every time a window
containing several files is closed, even if its only a modification of
a already existing "Recent Project" (unless its not modified). This
would allow jump back to several different settings and a "short
experiment" wont overwrite a useful configuration.

A possible variation might be to also autosave the project files. This
would however require a "detach" (or copy, or "freeze") function to
save current states for later recall.


I hope my descriptions were clear enough and some of my ideas can be
used.