Re: Try out new inline features [GSoC admin-ui]

[Margie]

Hey Zain,

Just tried out your new stuff.  Very cool!  A couple comments:

## I agree that a checkbox as a drag handle is confusing - I kept
trying to "check" it and didn't even realize it was a drag handle till
later

## I find the numbering that shows up on the comments in your sandbox
site to be confusing.  For example, I go to one of the pages and I see
one comment there, it says "Comment: #7".  ThenI add a new comment and
it says "Comment: #2".  Then after I save my new comment (#2), the
redisplayed page now shows #7 and #9.   It seems to me that the number
you are creating when one adds a new comment is just the number of
current comments + 1, and the number you are showing after it's been
saved is it's actual id.  I think that either __unicode__ or perhaps
some other thing like that should be used so that the user can specify
a name for it.  And for new comments (or whatever object is being
added), there should just be no name, because an arbitrary number
seems confusing.

## When I add a comment and then save, if there is an error in my
comment, I have to click through all the selectors to find the one
that has an error.  I think there should be an indicator on the
selector that there is an error in the entry.

Nice work, I like it!

Margie



On Jul 6, 2:20 am, Zain Memon  wrote:
> Hi everyone,
> In the last couple of weeks, I've implemented a bunch of inline features.
>
> Pictures speak louder than words, so I wrote up a quick blog post describing
> what's done:http://inzain.net/blog/2009/07/new-features-for-inlines/
>
> Also, I set up a server running my Django branch if you want to try them
> out:http://inzain.net:8000/admin/
>
> Play around and let me know what you think -- especially if you run into any
> bugs :)
>
> Until next week...ish,
> Zain
>
> ---
> My GSoC 
> proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Ulrich Petri]

Am 06.07.2009 um 11:20 schrieb Zain Memon:
> Play around and let me know what you think -- especially if you run  
> into any bugs :)

Hi,

looks nice. But there are a few things that don't quite "feel right"  
yet:

- The Drag handle looks like a checkbox as Adys already said
- The calculation of the drag offset seems off (at least on Mac): When  
you grab the handle (depending on where on the handle) the transparent  
representation jumps strangely.
- It would be nice if delete also was implemented as an DHTML/DOM  
effect (maybe not removing the item outright but chaning the color in  
the list and replacing the inline content with some text like "This  
item will be deleted. Click here to undo." or something like that)

Also there is the topic of unsaved changes, which i guess is the  
source of the desire for some sort of cancel button expressed in other  
posts.
One posibility would be some sort of confirmation dialog before  
leaving the page in case of unsaved changes, but personaly I think  
that's rather intrusive and annoying UI behaviour.
Maybe a better solution for that would be to show some sort of "dirty  
flag" (or simply a text "Unsaved changes!") in the bars next to the  
save buttons.

Thats it for now. I hope its helpful :)

Bye
Ulrich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Dougal Matthews]

I was just messing around with it and got this error;

http://dpaste.com/64095/

Not exactly sure what I did to cause it though.

Cheers,
Dougal


---
Dougal Matthews - @d0ugal
http://www.dougalmatthews.com/



2009/7/7 patrickk 

>
> another more severe problem ... I´m going to stop writing after this
> one ;-)
>
> when adding items with stacked-inlines, every comment automatically
> gets a value for the order-field. this means, when I´m adding a
> comment (without entering anything) and click on "save" I´m getting an
> error. this obviously shouldn´t be the case ...
>
> thanks,
> patrick
>
>
> On 7 Jul., 13:12, patrickk  wrote:
> > more feedback to your inline-solution:
> > ### if you use a draghandler for stacked-inlines, there should be a
> > draghandler for tabular-inlines as well (instead of dragging the whole
> > row).
> > ### deleting stacked-inlines: not sure if the delete-button should be
> > displayed with the selectors (near the draghandler). if not, there
> > should at least be an indication on the left-hand side if (or if not)
> > something has been marked for deletion.
> > ### from my point of view, the representation of an original object
> > with tabuar-inlines is redundant. within  the
> > paragraph can be removed.
> >
> > css-stuff:
> > ### the comma seperated integer field has the class "vTextField". not
> > nice.
> > ### why has URLField the class "vURLField" and EmailField has the
> > class "vTextField". very inconsistent here.
> > ### IPAddressField again misses the class, the same for filepathfield
> > and so on ... I´m not going to list everyhing here since you probably
> > know what I mean. it´s currently very messy (sometimes there is a
> > class, sometimes not, sometimes the class doesn´t relate to the
> > field ...).
> >
> > ### I´d use a different class for _every_ field. most of the time, it
> > ´s the same as vTextField, but it makes customization so much easier.
> > and it´s clean and coherent.
> >
> > ### at the change-list, the save-button (if you have forms on the
> > list) is within the paginator. shouldn´t be there, from my point of
> > view.
> >
> > regards,
> > patrick
> >
> > On 7 Jul., 11:16, Zain Memon  wrote:
> >
> > > Hey Patrick --
> >
> > > On Tue, Jul 7, 2009 at 1:04 AM, patrickk 
> wrote:
> >
> > > > [snip]
> >
> > > > there´s a lot more to say here, but I´m not sure if this is somehow
> > > > related to your work - not sure if you only work on the inline-stuff
> > > > or the admin-interface overall.
> >
> > > Both my GSoC project and future interests lie in improving the overall
> > > usability of the admin interface, so feel free to pitch away.
> >
> > > > besides the index-page, someone should take a look at the html/css.
> > > > the programming is a mess in certain places (e.g., every input-field
> > > > on the change-form has a class, but decimalfield and floatfield don
> > > > ´t). moreover, the naming of the css-classes doesn´t seem to be well
> > > > thought out.
> >
> > > I'll take a look at the decimalfield and floatfield classes. If there
> are
> > > other major inconsistencies, let me know and/or file a bug.
> >
> > > > something which is related to inlines: currently, with
> stacked-inlines
> > > > you´re having "comment #1 ...", "comment #2 ..." and so on on the
> left-
> > > > hand side. IMHO, you should display __unicode__ there (I hope you
> know
> > > > what I mean). because with 20 comments listed there, one has to click
> > > > through all items to actually see what´s in there ...
> > > > one more thing: it currently says "Add a choice" - I´m not sure if
> > > > this should be "Add a Choice" in order to be translated correctly.
> >
> > > It actually *is* the __unicode__ of the model -- I just happened to
> specify
> > > __unicode__ for comments as "Comment #%(id) @ %(time)".
> >
> > > All good stuff. Thanks!
> >
> > > Zain
> >
> >
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[patrickk]

another more severe problem ... I´m going to stop writing after this
one ;-)

when adding items with stacked-inlines, every comment automatically
gets a value for the order-field. this means, when I´m adding a
comment (without entering anything) and click on "save" I´m getting an
error. this obviously shouldn´t be the case ...

thanks,
patrick


On 7 Jul., 13:12, patrickk  wrote:
> more feedback to your inline-solution:
> ### if you use a draghandler for stacked-inlines, there should be a
> draghandler for tabular-inlines as well (instead of dragging the whole
> row).
> ### deleting stacked-inlines: not sure if the delete-button should be
> displayed with the selectors (near the draghandler). if not, there
> should at least be an indication on the left-hand side if (or if not)
> something has been marked for deletion.
> ### from my point of view, the representation of an original object
> with tabuar-inlines is redundant. within  the
> paragraph can be removed.
>
> css-stuff:
> ### the comma seperated integer field has the class "vTextField". not
> nice.
> ### why has URLField the class "vURLField" and EmailField has the
> class "vTextField". very inconsistent here.
> ### IPAddressField again misses the class, the same for filepathfield
> and so on ... I´m not going to list everyhing here since you probably
> know what I mean. it´s currently very messy (sometimes there is a
> class, sometimes not, sometimes the class doesn´t relate to the
> field ...).
>
> ### I´d use a different class for _every_ field. most of the time, it
> ´s the same as vTextField, but it makes customization so much easier.
> and it´s clean and coherent.
>
> ### at the change-list, the save-button (if you have forms on the
> list) is within the paginator. shouldn´t be there, from my point of
> view.
>
> regards,
> patrick
>
> On 7 Jul., 11:16, Zain Memon  wrote:
>
> > Hey Patrick --
>
> > On Tue, Jul 7, 2009 at 1:04 AM, patrickk  wrote:
>
> > > [snip]
>
> > > there´s a lot more to say here, but I´m not sure if this is somehow
> > > related to your work - not sure if you only work on the inline-stuff
> > > or the admin-interface overall.
>
> > Both my GSoC project and future interests lie in improving the overall
> > usability of the admin interface, so feel free to pitch away.
>
> > > besides the index-page, someone should take a look at the html/css.
> > > the programming is a mess in certain places (e.g., every input-field
> > > on the change-form has a class, but decimalfield and floatfield don
> > > ´t). moreover, the naming of the css-classes doesn´t seem to be well
> > > thought out.
>
> > I'll take a look at the decimalfield and floatfield classes. If there are
> > other major inconsistencies, let me know and/or file a bug.
>
> > > something which is related to inlines: currently, with stacked-inlines
> > > you´re having "comment #1 ...", "comment #2 ..." and so on on the left-
> > > hand side. IMHO, you should display __unicode__ there (I hope you know
> > > what I mean). because with 20 comments listed there, one has to click
> > > through all items to actually see what´s in there ...
> > > one more thing: it currently says "Add a choice" - I´m not sure if
> > > this should be "Add a Choice" in order to be translated correctly.
>
> > It actually *is* the __unicode__ of the model -- I just happened to specify
> > __unicode__ for comments as "Comment #%(id) @ %(time)".
>
> > All good stuff. Thanks!
>
> > Zain
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[patrickk]

more feedback to your inline-solution:
### if you use a draghandler for stacked-inlines, there should be a
draghandler for tabular-inlines as well (instead of dragging the whole
row).
### deleting stacked-inlines: not sure if the delete-button should be
displayed with the selectors (near the draghandler). if not, there
should at least be an indication on the left-hand side if (or if not)
something has been marked for deletion.
### from my point of view, the representation of an original object
with tabuar-inlines is redundant. within  the
paragraph can be removed.

css-stuff:
### the comma seperated integer field has the class "vTextField". not
nice.
### why has URLField the class "vURLField" and EmailField has the
class "vTextField". very inconsistent here.
### IPAddressField again misses the class, the same for filepathfield
and so on ... I´m not going to list everyhing here since you probably
know what I mean. it´s currently very messy (sometimes there is a
class, sometimes not, sometimes the class doesn´t relate to the
field ...).

### I´d use a different class for _every_ field. most of the time, it
´s the same as vTextField, but it makes customization so much easier.
and it´s clean and coherent.

### at the change-list, the save-button (if you have forms on the
list) is within the paginator. shouldn´t be there, from my point of
view.

regards,
patrick


On 7 Jul., 11:16, Zain Memon  wrote:
> Hey Patrick --
>
> On Tue, Jul 7, 2009 at 1:04 AM, patrickk  wrote:
>
> > [snip]
>
> > there´s a lot more to say here, but I´m not sure if this is somehow
> > related to your work - not sure if you only work on the inline-stuff
> > or the admin-interface overall.
>
> Both my GSoC project and future interests lie in improving the overall
> usability of the admin interface, so feel free to pitch away.
>
> > besides the index-page, someone should take a look at the html/css.
> > the programming is a mess in certain places (e.g., every input-field
> > on the change-form has a class, but decimalfield and floatfield don
> > ´t). moreover, the naming of the css-classes doesn´t seem to be well
> > thought out.
>
> I'll take a look at the decimalfield and floatfield classes. If there are
> other major inconsistencies, let me know and/or file a bug.
>
> > something which is related to inlines: currently, with stacked-inlines
> > you´re having "comment #1 ...", "comment #2 ..." and so on on the left-
> > hand side. IMHO, you should display __unicode__ there (I hope you know
> > what I mean). because with 20 comments listed there, one has to click
> > through all items to actually see what´s in there ...
> > one more thing: it currently says "Add a choice" - I´m not sure if
> > this should be "Add a Choice" in order to be translated correctly.
>
> It actually *is* the __unicode__ of the model -- I just happened to specify
> __unicode__ for comments as "Comment #%(id) @ %(time)".
>
> All good stuff. Thanks!
>
> Zain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Zain Memon]

Hey Patrick --

On Tue, Jul 7, 2009 at 1:04 AM, patrickk  wrote:

>
> [snip]
>
> there´s a lot more to say here, but I´m not sure if this is somehow
> related to your work - not sure if you only work on the inline-stuff
> or the admin-interface overall.


Both my GSoC project and future interests lie in improving the overall
usability of the admin interface, so feel free to pitch away.


> besides the index-page, someone should take a look at the html/css.
> the programming is a mess in certain places (e.g., every input-field
> on the change-form has a class, but decimalfield and floatfield don
> ´t). moreover, the naming of the css-classes doesn´t seem to be well
> thought out.


I'll take a look at the decimalfield and floatfield classes. If there are
other major inconsistencies, let me know and/or file a bug.


> something which is related to inlines: currently, with stacked-inlines
> you´re having "comment #1 ...", "comment #2 ..." and so on on the left-
> hand side. IMHO, you should display __unicode__ there (I hope you know
> what I mean). because with 20 comments listed there, one has to click
> through all items to actually see what´s in there ...
> one more thing: it currently says "Add a choice" - I´m not sure if
> this should be "Add a Choice" in order to be translated correctly.


It actually *is* the __unicode__ of the model -- I just happened to specify
__unicode__ for comments as "Comment #%(id) @ %(time)".

All good stuff. Thanks!

Zain

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Tom Evans]

On Tue, 2009-07-07 at 09:45 +0100, Andy Baker wrote:
> Mmmm. That's a fair point but that article was written before web
> applications were so application-ey and expectations may well have
> changed. (I've noticed a lot of semi-modal dialogs in web apps
> complete with 'cancel' buttons and with javascript dialogs the back
> button doesn't do what Jakob implies people expect)
> 
> So there is a lot of subtlety here and I'd like to get more data. It
> never occurred to me that Cancel was needed until I watched a user
> flounder when they didn't know how to get out of the change screen.
> 
> > Usability experts disagree with you vehemently:
> >
> > http://www.useit.com/alertbox/2416.html
> >
> > Cheers
> >
> > Tom
> >
> >

In this case though, it is not a modal dialogue box, it is a large form,
with a bunch of form inlines, much like a lot of other web pages. The
advice may be old, but it is still valid.

Cancel buttons can bring a lot of confusion to the mix, particularly
when you actually start doing application-style things like AJAX
modification of the models, (some) users will expect the cancel button
to revert all changes you've made since loading the page (including
committed changes made through AJAX). It just gets more confusing for
the average user to understand. 

Cheers

Tom


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Andy Baker]

Mmmm. That's a fair point but that article was written before web
applications were so application-ey and expectations may well have
changed. (I've noticed a lot of semi-modal dialogs in web apps
complete with 'cancel' buttons and with javascript dialogs the back
button doesn't do what Jakob implies people expect)

So there is a lot of subtlety here and I'd like to get more data. It
never occurred to me that Cancel was needed until I watched a user
flounder when they didn't know how to get out of the change screen.

> Usability experts disagree with you vehemently:
>
> http://www.useit.com/alertbox/2416.html
>
> Cheers
>
> Tom
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Tom Evans]

On Mon, 2009-07-06 at 07:26 -0700, andybak wrote:
> Nice!
> 
> Are you planning to do anything to finesse the behaviour of the
> 'delete' button? It would be nice (especially on selector inlines) if
> it looked like items disappeared immediately.
> 
> I also feel the admin change pages needs a 'cancel' button. It's quite
> counter-intuitive that the way to leave the page without saving
> changes is to simply navigate away without clicking save. This has
> come up in a couple of quick usability tests. (Incidentally - is
> anyone else doing usability tests on the Django Admin? It would be
> nice to pool findings)

Usability experts disagree with you vehemently:

http://www.useit.com/alertbox/2416.html

Cheers

Tom


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[patrickk]

hi zain,

I´m not sure if this is the right place to start a discussion about
usability testing, but I still post the main issues here ... see
http://code.google.com/p/django-grappelli/wiki/djangoissues for
further details.

the main problem for our clients is the admin index page and how
"installed apps" are listed there. I know that it´s possible to
customize this page, but that´s not the point (because it leads to
unwanted behaviour).
when I have to explain to my customers why apps are listed the way
they are, it´s always getting complicated. customers are not
interested in something like "installed apps" - they don´t even know
what apps are (and they don´t have to).
a simple example: you´re having an app "auth" with "groups" and
"users". and you´re also having an app "user" with a "user profile".
of course, you want to list "groups", "users" and "user profiles" on
ONE place on the admin index page. my clients always call me for
something like "I can´t find the users profile" (because there are 124
models listed between the app "auth" and the app "user").
IMHO, that´s currently the biggest weakness of the admin-interface
when it comes to "usability".

there´s a lot more to say here, but I´m not sure if this is somehow
related to your work - not sure if you only work on the inline-stuff
or the admin-interface overall.
besides the index-page, someone should take a look at the html/css.
the programming is a mess in certain places (e.g., every input-field
on the change-form has a class, but decimalfield and floatfield don
´t). moreover, the naming of the css-classes doesn´t seem to be well
thought out.

something which is related to inlines: currently, with stacked-inlines
you´re having "comment #1 ...", "comment #2 ..." and so on on the left-
hand side. IMHO, you should display __unicode__ there (I hope you know
what I mean). because with 20 comments listed there, one has to click
through all items to actually see what´s in there ...
one more thing: it currently says "Add a choice" - I´m not sure if
this should be "Add a Choice" in order to be translated correctly.

thanks,
patrick


On 7 Jul., 08:21, Zain Memon  wrote:
> Thanks for the feedback, everyone. I'll focus on improving error handling
> and styles to make reordering more intuitive.
> patrickk and andybak: I'd love to hear your findings from usability tests. I
> will be in a pretty good position to implement fixes you suggest (barring
> community approval) once GSoC is over.
>
> Zain
>
> On Mon, Jul 6, 2009 at 10:25 AM, patrickk  wrote:
>
> > @aniybak: yes, we´re doing usability-tests very frequently. that´s one
> > reason why we came up with django-grappelli ...
>
> > btw, I absolutely agree with the "cancel-button".
>
> > about the delete-button: IMHO, one needs the possibility to undo the
> > deletion - that´s why it´s almost impossible to let items disappear.
>
> > regards,
> > patrick
>
> > On 6 Jul., 16:26, andybak  wrote:
> > > Nice!
>
> > > Are you planning to do anything to finesse the behaviour of the
> > > 'delete' button? It would be nice (especially on selector inlines) if
> > > it looked like items disappeared immediately.
>
> > > I also feel the admin change pages needs a 'cancel' button. It's quite
> > > counter-intuitive that the way to leave the page without saving
> > > changes is to simply navigate away without clicking save. This has
> > > come up in a couple of quick usability tests. (Incidentally - is
> > > anyone else doing usability tests on the Django Admin? It would be
> > > nice to pool findings)
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Zain Memon]

Thanks for the feedback, everyone. I'll focus on improving error handling
and styles to make reordering more intuitive.
patrickk and andybak: I'd love to hear your findings from usability tests. I
will be in a pretty good position to implement fixes you suggest (barring
community approval) once GSoC is over.

Zain

On Mon, Jul 6, 2009 at 10:25 AM, patrickk  wrote:

>
> @aniybak: yes, we´re doing usability-tests very frequently. that´s one
> reason why we came up with django-grappelli ...
>
> btw, I absolutely agree with the "cancel-button".
>
> about the delete-button: IMHO, one needs the possibility to undo the
> deletion - that´s why it´s almost impossible to let items disappear.
>
> regards,
> patrick
>
>
> On 6 Jul., 16:26, andybak  wrote:
> > Nice!
> >
> > Are you planning to do anything to finesse the behaviour of the
> > 'delete' button? It would be nice (especially on selector inlines) if
> > it looked like items disappeared immediately.
> >
> > I also feel the admin change pages needs a 'cancel' button. It's quite
> > counter-intuitive that the way to leave the page without saving
> > changes is to simply navigate away without clicking save. This has
> > come up in a couple of quick usability tests. (Incidentally - is
> > anyone else doing usability tests on the Django Admin? It would be
> > nice to pool findings)
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[patrickk]

@aniybak: yes, we´re doing usability-tests very frequently. that´s one
reason why we came up with django-grappelli ...

btw, I absolutely agree with the "cancel-button".

about the delete-button: IMHO, one needs the possibility to undo the
deletion - that´s why it´s almost impossible to let items disappear.

regards,
patrick


On 6 Jul., 16:26, andybak  wrote:
> Nice!
>
> Are you planning to do anything to finesse the behaviour of the
> 'delete' button? It would be nice (especially on selector inlines) if
> it looked like items disappeared immediately.
>
> I also feel the admin change pages needs a 'cancel' button. It's quite
> counter-intuitive that the way to leave the page without saving
> changes is to simply navigate away without clicking save. This has
> come up in a couple of quick usability tests. (Incidentally - is
> anyone else doing usability tests on the Django Admin? It would be
> nice to pool findings)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[andybak]

Nice!

Are you planning to do anything to finesse the behaviour of the
'delete' button? It would be nice (especially on selector inlines) if
it looked like items disappeared immediately.

I also feel the admin change pages needs a 'cancel' button. It's quite
counter-intuitive that the way to leave the page without saving
changes is to simply navigate away without clicking save. This has
come up in a couple of quick usability tests. (Incidentally - is
anyone else doing usability tests on the Django Admin? It would be
nice to pool findings)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[Adys]

Hi Zain

This looks very good. One minor complaint; the checkbox-ish design of
the handle is a bit counter-intuitive. Is it possible to have it on
the right like the other handle, and only be able to grab it from the
left side (gmail-ish interface)?

Hoping this makes into trunk soon!

J

On Jul 6, 11:20 am, Zain Memon  wrote:
> Hi everyone,
> In the last couple of weeks, I've implemented a bunch of inline features.
>
> Pictures speak louder than words, so I wrote up a quick blog post describing
> what's done:http://inzain.net/blog/2009/07/new-features-for-inlines/
>
> Also, I set up a server running my Django branch if you want to try them
> out:http://inzain.net:8000/admin/
>
> Play around and let me know what you think -- especially if you run into any
> bugs :)

>
> Until next week...ish,
> Zain
>
> ---
> My GSoC 
> proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Try out new inline features [GSoC admin-ui]

[patrickk]

very nice ...

some things I´ve came across:
- the ordering is not preserved in case of errors.
- with stacked inlines, an error should be indicated on the left-hand
side (with comment-selectors). otherwise one has to click through all
selectors.
- with stacked inlines, there´s something wrong with the numbers when
clicking on "add comment". sometimes the numbers are right, sometimes
not.

hope this will find its way to the trunk very soon.

thanks,
patrick


On 6 Jul., 11:20, Zain Memon  wrote:
> Hi everyone,
> In the last couple of weeks, I've implemented a bunch of inline features.
>
> Pictures speak louder than words, so I wrote up a quick blog post describing
> what's done:http://inzain.net/blog/2009/07/new-features-for-inlines/
>
> Also, I set up a server running my Django branch if you want to try them
> out:http://inzain.net:8000/admin/
>
> Play around and let me know what you think -- especially if you run into any
> bugs :)
>
> Until next week...ish,
> Zain
>
> ---
> My GSoC 
> proposal:http://inzain.net/blog/2009/05/django-gsoc-09-admin-ui-improvements/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---