New repo in kdereview: KRecorder

Devin espidev at gmail.com
Wed Nov 9 21:45:35 GMT 2022


Hi Nate,

I've done some work on addressing the feedback:

> The app should have a Bugzilla component and its "Report a bug" button should take users there, as we have been migrating towards for other mobile apps recently.

Resolved

> When I open the app for the first time on the desktop, I get a
> mobile-specific floating action button at the bottom of the view which
> doesn't make it clear how I can record something:
>
> https://i.imgur.com/1xSDJkC.jpg
>
> On the desktop, we should not show the FAB, give the placeholder message
> a "Make New Recording" action button, and then when the placeholder
> message isn't visible, show a button for that action on the toolbar.
>
> (and IMO that would be better for mobile too)

I've switched over the FAB to be a page action on widescreen. There is
now a placeholder message on the default page to create a new
recording.

I personally think the FAB should stay on mobile, it is easier to
reach and I think is fairly obvious for users that it is a record
button.

> When there are no recordings, the right pane is superfluous, and its message refers to things that don't exist.

The message has been updated. I think it is important to keep the two
panel approach on widescreen since I think it can be disorienting for
the panel setup to change when entering recordings.

> The left pane's placeholder message is off-center with narrow windows.

Fixed.

> When I click on the Settings button, instead of the settings view
> appearing as either a standalone window (as I would expect for a desktop
> app) or an embedded page (as I would expect for a mobile app), it opens
> as a view within a Kirigami.OverlaySheet, which is weird. Also, the use
> of the new Kirigami mofile form components creates a "frames within
> frames" effect that I find slightly offputting:
>
> https://i.imgur.com/5LN7cBJ.jpg
>
> When I click on any of the settings, they open in *new* OverlaySheets
> which feels quite weird. And the About page does open as a real page,
> but when I click the back button it doesn't take be back to where I was
> before; it closes the OverlaySheet I was looking at amd I'm back on the
> main view
>
> Overall I would recommend using full-window pages (or a standalone
> window on desktop) here, rather than an OverlaySheet.

I've switched over the settings dialog to be a window on widescreen.

> The "Audio Quality" setting doesn't give any mention of a trade-off
> between quality and file size (which I assume it at play here), leaving
> me to wonder why I wouldn't always make it the highest value, and why it
> doesn't default to that itself.

I've added a label clarifying this.

> On the recording page, the "stop recording" button is red which is typically our "destructive action" color.

I've attempted to use other colours, as well as the selection colour,
but they either don't contrast when flat, or don't really seem like
buttons.

I would argue that this is a destructive action, because it stops the
recording without any way of going back. This colour is also typically
used for stop buttons on other platforms, so I would not say that it
is particularly out of place, in my opinion.

> The default filename for all recordings is "clip_0001", even if a file
of that name already exists.

Fixed.

> The UI does not make it clear where files get saved to during the save
> process. I took a guess and checked in ~/Music, which was correct but
> that's a weird place for voice recordings which are clearly not music.
>
> I found the actual file path on the edit dialog, but we should show the
> full file path elsewhere too, at least on the desktop where users are
> more likely to care about the exact location of where files live.

Added the storage location to the recording save dialog.

> The "Edit" action for the individual list items should probably be renamed to "Rename" since that's all you can do there. Same for the title of the OverlaySheet it spawns

Switched.

> On the "Editing [name]" OverlaySheet, the filename field's label is "Audio Input:" which seems inappropriate.

Fixed.

> Playback buttons can get cut off with short windows:

Fixed.

> None of the icons-only buttons on the recording or playback pages have
tooltips.

Fixed.

Regards,
Devin

On Wed, Oct 26, 2022 at 11:34 AM Nate Graham <nate at kde.org> wrote:
>
> Pretty nice app.
>
>
> The app should have a Bugzilla component and its "Report a bug" button
> should take users there, as we have been migrating towards for other
> mobile apps recently.
>
>
> Some UI review now:
>
>
> When I open the app for the first time on the desktop, I get a
> mobile-specific floating action button at the bottom of the view which
> doesn't make it clear how I can record something:
>
> https://i.imgur.com/1xSDJkC.jpg
>
> On the desktop, we should not show the FAB, give the placeholder message
> a "Make New Recording" action button, and then when the placeholder
> message isn't visible, show a button for that action on the toolbar.
>
> (and IMO that would be better for mobile too)
>
> ----------------------------------------
>
> When there are no recordings, the right pane is superfluous, and its
> message refers to things that don't exist.
>
> ----------------------------------------
>
> The left pane's placeholder message is off-center with narrow windows.
>
> ----------------------------------------
>
> When I click on the Settings button, instead of the settings view
> appearing as either a standalone window (as I would expect for a desktop
> app) or an embedded page (as I would expect for a mobile app), it opens
> as a view within a Kirigami.OverlaySheet, which is weird. Also, the use
> of the new Kirigami mofile form components creates a "frames within
> frames" effect that I find slightly offputting:
>
> https://i.imgur.com/5LN7cBJ.jpg
>
> When I click on any of the settings, they open in *new* OverlaySheets
> which feels quite weird. And the About page does open as a real page,
> but when I click the back button it doesn't take be back to where I was
> before; it closes the OverlaySheet I was looking at amd I'm back on the
> main view
>
> Overall I would recommend using full-window pages (or a standalone
> window on desktop) here, rather than an OverlaySheet.
>
> ----------------------------------------
>
> The "Audio Quality" setting doesn't give any mention of a trade-off
> between quality and file size (which I assume it at play here), leaving
> me to wonder why I wouldn't always make it the highest value, and why it
> doesn't default to that itself.
>
> ----------------------------------------
>
> On the recording page, the "stop recording" button is red which is
> typically our "destructive action" color.
>
> ----------------------------------------
>
> The default filename for all recordings is "clip_0001", even if a file
> of that name already exists.
>
> ----------------------------------------
>
> The UI does not make it clear where files get saved to during the save
> process. I took a guess and checked in ~/Music, which was correct but
> that's a weird place for voice recordings which are clearly not music.
>
> I found the actual file path on the edit dialog, but we should show the
> full file path elsewhere too, at least on the desktop where users are
> more likely to care about the exact location of where files live.
>
> ----------------------------------------
>
> The "Edit" action for the individual list items should probably be
> renamed to "Rename" since that's all you can do there. Same for the
> title of the OverlaySheet it spawns
>
> ----------------------------------------
>
> On the "Editing [name]" OverlaySheet, the filename field's label is
> "Audio Input:" which seems inappropriate.
>
> ----------------------------------------
>
> Playback buttons can get cut off with short windows:
>
> https://i.imgur.com/Fl0oIUf.jpg
>
> None of the icons-only buttons on the recording or playback pages have
> tooltips.
>
>
>
>
>
>
> On 10/26/22 09:08, Devin wrote:
> > Any other comments or issues to address?
> >
> > Thanks,
> > Devin
> >
> > On Fri, Oct 21, 2022 at 6:21 PM Albert Astals Cid <aacid at kde.org> wrote:
> >>
> >> El divendres, 21 d’octubre de 2022, a les 23:55:28 (CEST), Devin va escriure:
> >>>> make install doesn't install any icon for me with the current master.
> >>>
> >>> I just checked and indeed, the method I changed to using
> >>> ecm_install_icons doesn't seem to have the behaviour I thought it did.
> >>> I hadn't verified it properly because the icon was already
> >>> preinstalled for me.
> >>>
> >>> I reverted to the prior commit which installed the icon fine (it
> >>> should be installing to
> >>> /usr/share/icons/hicolor/scalable/apps/krecorder.svg), does this not
> >>> work for you on X11? I double checked and the application icon shows
> >>> for me.
> >>
> >> https://invent.kde.org/plasma-mobile/krecorder/-/merge_requests/17
> >>
> >> Makes it work for me (when starting from the terminal)
> >>
> >> Cheers,
> >>    Albert
> >>
> >>>
> >>> Thanks,
> >>> Devin
> >>>
> >>> On Fri, Oct 21, 2022 at 5:08 PM Albert Astals Cid <aacid at kde.org> wrote:
> >>>> El divendres, 21 d’octubre de 2022, a les 23:00:46 (CEST), Devin va
> >> escriure:
> >>>>>> The app doesn't have an icon when run in X11
> >>>>>
> >>>>> Hmm, the location the icon installed to might be non-standard. I think
> >>>>> I've fixed it on master now by copying the way other KDE apps install
> >>>>> the icon.
> >>>>
> >>>> make install doesn't install any icon for me with the current master.
> >>>>
> >>>> Cheers,
> >>>>
> >>>>    Albert
> >>
> >>
> >>
> >>


More information about the kde-core-devel mailing list