Hi Eli!
Thanks for your writeup!
These feedback things are things we need to hear multiple times,
to really drive the message home,
so that we can be better,
address real life problems, and also
so that we can be held accountable for what we do.
Let me know if I’ve misinterpreted any of the following:
Feedback #1: Bring back tables (ok, we will do this :) I’ve heard enough voices
to make it happen!)
Feedback #2: Default _all_docs page doesn’t show enough relevant information
Fair enough, this is something I think we should default with
include_docs=true, but apparently it breaks some people’s browsers because the
content of the data is extremely large. I’d like to revisit this idea though.
Feedback #3: Colors
This is sensitive topic, and I learned this when I first started
working in industry a few years ago: don’t question the colors.
And then **definitely, without a doubt** do not use coding skills to
change other peoples colors :)
I’m glad you mentioned it so I didn’t have to.
What I’m hearing is that you’d like the text colors to be consistent
across the UI.
And that it’s disorienting to switch background contexts that quickly.
Feedback #4: There's no obvious way to get to a nicely-rendered document
overview.
> — Could you expand on this? I’m not getting a clear idea of the
problem — <
Also RE:
> I really want to click on the red ID 5d964eab30b5656190b416bff6210b69
> header part;
You can double click on the document ‘card’, and it will take you to
the full page editor!
Not very intuitive, but once Kxepal told me it was possible, I love it,
I do the double click all the time now :D
FWIW, I would also like the ability to directly edit the document
‘card’, from the _all_docs page.
I think that would be neat.
Feedback #5: Keep JSON, as valid JSON, for c+p
Feedback #6: too much whitespace
:( we hear this all the time. I’ll bring it up to the designers.
Feedback #7: Reverse-breadcrumb
This is a good idea !
It would also clarify how closely CouchDB API works with Fauxton urls,
and thus is another vehicle to teach people who are new to how CouchDB and REST
APIs work. There used to be a UI for Cloudant that did this really well! Maybe
we can convince people to bring it into Fauxton.
Feedback #8: Query Options
Interesting. I had not considered putting Query Options in the View
Sidebar.
I had a proposal to bring a duplicate button for include_docs=true
option from the tray, and into the top of document cards area. Query Options
can effect different types of calls, but it’s an interesting idea to have it
built into the views sidebar. As I am thinking about this, I am liking the idea
more and more. We could make a component out of it, and use it everywhere that
needs query options.
Feedback #9: Views editing and viewing page
This needs work :/
Feedback #10: design/documents/views/etc needs better navigation
This needs work :/
Now the big question:
> What set of cases has the fauxton team been designing
> towards?
This is really a great question. :D :D :D
For the most part**, me, Garren, Ben, Robert and me have been implementing new
features, and taking care of the code base. We are in the midst of converting
our code to use ReactJS instead of BackboneJS. So while we have a lot of coding
help, we sometime neglect design, because we feel things must work first to be
useful.
**some notable people come and help us rebuild Fauxton as well, when they have
time, and we are very grateful for their help ;)
For me personally, I started working for Cloudant in September, and for a
couple of months I was swimming in CouchDB vs Cloudant data, just trying to
make sense of how everything worked.
Then I tried to fix some JIRA tickets, and sneak in making the CSS better.
Usually I am coding, although I wish I could spend much more time on the
designing and information architecture mapping part.
Cloudant has a new team of designers. They are new, and are just learning about
CouchDB/Cloudant. We’ve asked them to take a look at CouchDB and how it could
be better. They are interested in feedback, but for a different reason from
what I’ve asked the mailing list for. I just wanted somethings to put into my
presentation, but I am also very excited that I am getting this type of
in-depth feedback! It’s really refreshing to hear.
I usually go on IRC, and try to help out with questions that I can help with.
This is where I get a sense of how people are using Fauxton, and what is
confusing to them for CouchDB. Then I try to make it less confusing for them.
Then I consult with the experts about why things are the way they are, and
usually there is a reasonable explanation.
Generally though we have a few goals we try to achieve:
1. Make it easy for a new couchDB person to get setup with databases and
documents
2. Stick closely to the API
3. Give information
I hope I got everything.
Thanks for your thoughts Eli :)
Feel free to email more, as you see them see more things, although no promises
on *when* :(
But do not to worry….
we will be….
eventually consistent.
:)
Michelle
---------------------------------------------------------------------------------------------------------
I’m pretty sure it doesn’t work this way, but:
ping @garrensmith
@benkeen
@robertkowalski
could you guys chime in when you have a moment, if i’ve missed anything or
gotten something wrong :)
> On Aug 15, 2015, at 12:28 AM, Eli Stevens (Gmail) <[email protected]>
> wrote:
>
> Hi,
>
> Thanks for asking for user feedback!
>
> I just installed the default new(ish?) fauxton via npm, etc. from the
> instructions at https://www.npmjs.com/package/fauxton (not sure if
> that's as up to date as it could be). Here are my (hopefully
> constructive) opinions. In general, I agree with a lot of James'
> points, and it sounds like work is already underway to address the
> biggest ones I have, but I'd like to add my vote to the record.
>
> - The default view output is a downgrade from v1.6.1 futon, especially
> when it comes to _all_docs. This one's a deal-breaker for me ATM.
> Consider the following paste from the output:
>
> ID 5d964eab30b5656190b416bff6210b69
>
> {
> "_id": "5d964eab30b5656190b416bff6210b69",
> "_rev": "1-9462c2ccb60cb932e5003df4b148f712",
> "value": {
> "rev": "1-9462c2ccb60cb932e5003df4b148f712"
> },
> "key": "5d964eab30b5656190b416bff6210b69"
> }
>
> I'm shown the ID three times and the _rev twice, with no other useful
> information. By separating the key+ID into the left column and the
> value into the right, it's much, much easier to scan the keys to find
> data I'm interested in. The syntax highlighting on the right in futon
> makes it easier to visually parse the value. It would be nice if
> fauxton pretty-printed the value, unlike the blob that futon has.
>
> - The alternate choice of black-on-white and white-on-grey looks nice,
> but isn't easy on the eyes, esp. when having to flick my eyes back and
> forth between a dark sidebar, then a light sidebar and then the dark
> data content. The database overview looks great; please use that color
> scheme for the data content.
>
> - There's no obvious way to get to a nicely-rendered document
> overview. Having the futon two-column table with sorted top-level keys
> on the left and values on the right is very useful. I'm not a huge fan
> of how futon does editing from that document view, but it has definite
> advantages when dealing with large documents. This one is also
> probably a deal-breaker for me, but not as badly as the previous
> point.
>
> I really want to click on the red ID 5d964eab30b5656190b416bff6210b69
> header part; it not going to that document is jarring.
>
> - I like that fauxton doesn't hide the double-quotes on string keys;
> being able to copy valid JSON directly out of the UI is nice.
>
> - I agree with James that the default font size is too large, and
> wouldn't mind slightly less margin/padding in general.
>
> - I would highly recommend removing the "fixed" from:
>
> table.table {
> table-layout: fixed;
> }
>
> This results in a ton of wasted whitespace, and line-wrapping of DB
> names since that column isn't wide enough (which results in yet more
> wasted whitespace vertically). I have a high resolution screen for a
> reason; let me use it! :)
>
> - The page title should be a reverse-breadcrumb of doc_id < db_name;
> or view_name < design_doc_id < db_name; etc.
>
> For an example of the kind of data that I work with regularly, see the
> lightly-anonymized json here:
>
> https://gist.github.com/elistevens/a7d43fb306373f88644b
>
> And an example view that has representative data for my typical use would be:
>
> (doc) ->
> for k,v in doc.state
> emit [doc._id, k], v
>
> My typical use case is "the UI doesn't look the way I expect; let me
> drill down into the DB to see if the data powering that part looks
> off." Being able to drill down into a specific sub-key quickly is
> important. If it would be helpful, I'd be happy to pay attention to my
> day-to-day usage of futon and report more accurate usage data.
>
> - I'd like to be able to see and edit the query options I have in
> place in full detail without having to click on "query options" and
> scroll through a little text box. For example, I just entered this as
> part of some real-world debugging I'm doing for my day job:
>
> startkey:
> ["xyz_summary_2015-08-14_19.02.26.164089_9b11e5b33997ef5cc844b992b6e934a7",
> "summaryRmsChart_data"]
> endkey:
> ["xyz_summary_2015-08-14_19.02.26.164089_9b11e5b33997ef5cc844b992b6e934a7",
> "summaryRmsChart_summary", {}]
>
> Everything in the query options dropdown seems like it should all be
> in the view sidebar, under the map and reduce sections (and tightened
> up).
>
> - The "Views are the primary tools for querying and reporting." text
> can go away. 99% of users aren't going to need the tutorial once they
> start using the UI for real.
>
> - The views "Database" section duplicates the text two sections above
> and can also go away. However, the title bar db name isn't clickable,
> which is surprising.
>
> - The "Design Document" and "Index name" sections look like they
> should be navigational, but they're not. Having to go back out to all
> docs to switch to another view (even in the same design doc) is
> clunky. The futon dropdown was fast and straightforward here (though
> I'd be fine losing futon's approach of having the built-in views
> included as well). Having a separate "copy to new design doc and/or
> view name" button at the bottom would retain the current
> functionality.
>
> On Fri, Aug 14, 2015 at 10:25 AM, Michelle Phung <[email protected]> wrote:
>> I didn't realize that Fauxton would be used as a debugging tool!
>
> I was surprised to read this, since that's basically the only thing
> that I use futon for, and am having a hard time imagining other use
> cases (I think that this speaks to both the strength of CouchDB being
> able to address a wide array of uses, and to weaknesses in my
> imagination ;). What set of cases has the fauxton team been designing
> towards?
>
> Thanks for reading,
> Eli
>
