Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orion-dev] UX Concepts for discussion

Thought I'd rename the thread so our replies to Anton's request stood out from the pre-meeting discussion...

The two themes that I would like to see us discuss sooner than later:
1) editor and navigation
2) what does the breadcrumb mean? (this one wasn't on the mind map,but came up in the email. To some folks, it is "the thing that takes you to the navigator" and so it could be seen as part of theme #1. To other folks, it's a "scoper" on the current page. I think we need to come to grips with what it means, how people use it

The mind map is very cool...!....
one suggestion is that if there were an accompanying text list, I could Ctrl+F on the wiki page to see that something is on the map. I had to read it pretty carefully to figure out if "breadcrumb" was mentioned.

susan

Inactive hide details for Anton McConville ---05/02/2012 01:33:12 PM---Hi, Following up from yesterday's meeting and from the gAnton McConville ---05/02/2012 01:33:12 PM---Hi, Following up from yesterday's meeting and from the great email feedback

From: Anton McConville <Anton.McConville@xxxxxxxxxx>
To: Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date: 05/02/2012 01:33 PM
Subject: Re: [orion-dev] User Experience Call
Sent by: orion-dev-bounces@xxxxxxxxxxx





Hi,

Following up from yesterday's meeting and from the great email feedback that was sent to Orion-dev, there is now UX wiki page to serve as a starting point for evolving our work flows and user experience.

http://wiki.eclipse.org/Orion/User_Experience

The emails provided real world observations on how things ( don't ) work for us right now. In the first UX meeting yesterday we also suggested that reviewing the broader use cases of Orion could help structure the overall user experience well, and left the meeting with an aim to more thoroughly understand those use cases, and to work more on identifying the work flows that matter most to them.

The bottom up observations from the emails should slot into those workflows ( for example, logging in, creating a site, creating folders/files and switching/editing between css, html and js, saving, testing, publishing covers a lot of themes ). This should provide us with a catalogue of patterns/approaches that we want to get right.

In 0.5 we already started work on a few areas that we wanted to improve on. To help prioritize the next steps, please take a look at the material on the wiki - see if you agree with the themes in the mind map, or suggest more themes or other areas within them to consider. Look at the user types and their needs to see if you agree that those are the use cases we should cater to.

For the next UX meeting, I propose we focus on a theme. Prepare and turn up to the meeting with some ideas on how we'd like each area to be in an ideal world - in the context of a high level use case. As much as the feedback is valuable on what isn't working for us now, it'd be great to also have some feedback on what we'd like to see - to help get it right.

Please reply with your top three themes that you'd like to prioritize in the next UX meetings, and in our work to improve them.

Thanks.

Anton


Inactive hide details for Mike Wilson---05/02/2012 12:31:37 PM---> Not sure if it is doable on server side but...Mike Wilson---05/02/2012 12:31:37 PM---> Not sure if it is doable on server side but...
      From:

Mike Wilson/Ottawa/IBM@IBMCA
      To:

Orion developer discussions <orion-dev@xxxxxxxxxxx>
      Date:

05/02/2012 12:31 PM
      Subject:

Re: [orion-dev] User Experience Call




> Not sure if it is doable on server side but...
>
Presumably it is if the server is running on top of a file system that is based on an Eclipse Workspace (i.e. because you could tell when things had changed based on the Workspace change notification).

McQ.


Inactive hide details for Libing Wang---2012/05/02 10:32:26--->> I would be happy to wait longer for a search result if that woLibing Wang---2012/05/02 10:32:26--->> I would be happy to wait longer for a search result if that would mean it could ensure the search

From:
Libing Wang/Ottawa/IBM@IBMCA
To:
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Cc:
Orion developer discussions <orion-dev@xxxxxxxxxxx>, orion-dev-bounces@xxxxxxxxxxx
Date:
2012/05/02 10:32
Subject:
Re: [orion-dev] User Experience Call
Sent by:
orion-dev-bounces@xxxxxxxxxxx




>> I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
>Me too. Is this doable with the current architecture?

Not sure if it is doable on server side but lets assume that server is aware of the "not updated yet" state when a search request is sent to a folder.
My concern is what the UI gesture will be? Are we going to say "please wait. Index is being updated"?
If that is true I would rather switching to a crawling search instead of waiting for index being updated, where at least I am seeing search progress...

Libing



Inactive hide details for Mike Wilson---05/02/2012 08:56:07 AM---> I would be happy to wait longer for a search result if that Mike Wilson---05/02/2012 08:56:07 AM---> I would be happy to wait longer for a search result if that would mean it could ensure the search

From:
Mike Wilson/Ottawa/IBM@IBMCA
To:
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:
05/02/2012 08:56 AM
Subject:
Re: [orion-dev] User Experience Call
Sent by:
orion-dev-bounces@xxxxxxxxxxx




> I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
Me too. Is this doable with the current architecture?

McQ.


Inactive hide details for Kris De Volder ---2012/05/01 18:44:05---> This worked for me. I wonder if you typed the line and thenKris De Volder ---2012/05/01 18:44:05---> This worked for me. I wonder if you typed the line and then immediately searched for it. That is a

From:
Kris De Volder <kdvolder@xxxxxxxxxx>
To:
Orion developer discussions <orion-dev@xxxxxxxxxxx>
Date:
2012/05/01 18:44
Subject:
Re: [orion-dev] User Experience Call
Sent by:
orion-dev-bounces@xxxxxxxxxxx




> This worked for me. I wonder if you typed the line and then immediately searched for it. That is a big current limitation in our search - because it is index based and the
> index may not be up to date at the moment you search.


It was actually quite an old file. Not something I just entered. Now that I try it again it actually does work.
Not sure why it didn't work earlier. Now I'm starting to think maybe I imagined it :-)

Problems of indexes being 'out of date' are probably adding to the feeling of 'unreliability' I get.
Though I can't say whether or not this particular case was really an example of that.

I would be happy to wait longer for a search result if that would mean it could ensure the search index is up-to-date
before it starts searching.

Kris



      Kris De Volder <kdvolder@xxxxxxxxxx> wrote on 05/01/2012 03:27:56 PM:
      > Here's a different type of example (no white space involved).
      >
      > Say I have this line of code:
      >
      > response.end("Hello Kris");
      >
      > Now search from navigator for 'Kris'.
      >
      > It doesn't find the line above.

      This worked for me. I wonder if you typed the line and then immediately searched for it. That is a big current limitation in our search - because it is index based and the index may not be up to date at the moment you search.

      It is also definitely true that it is harder to get an index-based search to be "perfect" compared to a manual file system crawl on each search. We have been making steady improvements but I'm sure there are still problematic cases. On the flip side, our search is vastly more performant and scalable than a naive file system search. When I go back to Eclipse desktop now I am struck by how incredibly slow it is. I just did a search for "Kris" in my Eclipse desktop workspace, which isn't particularly large, and it took over two minutes. The same search on my Orion workspace, which is slightly smaller but comparable in size, took under 300ms. Performance certainly doesn't excuse any failure to find a match, but it's definitely a consideration for Orion to scale up beyond small applications and workspaces.

      Everyone please continue to report bugs if you have a search case that doesn't work...

      John
      _______________________________________________
      orion-dev mailing list
      orion-dev@xxxxxxxxxxx

      https://dev.eclipse.org/mailman/listinfo/orion-dev



_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev
_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx

https://dev.eclipse.org/mailman/listinfo/orion-dev_______________________________________________
orion-dev mailing list
orion-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orion-dev

GIF image

GIF image


Back to the top