couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: Project Fauxton Feedback
Date Sat, 15 Aug 2015 04:28:33 GMT
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 <michellep@apache.org> 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

Mime
View raw message