
The Case Against Marzipan - bangonkeyboard
https://uluroospeaks.com/articles/the-case-against-marzipan.php
======
giobox
The saddest part for me is that between the HIG (Apple speak for their "Human
Interface Guidelines" documentation) and their own apps, Apple used to set a
great standard that inspired third party developers to commit to a similar
level of UX polish. Apple's design awards handed out at WWDC used to be a real
badge of honor, coming from a company as UX focused as they are.

The four Marzipan apps Apple themselves have shipped in Mojave are garbage by
the past standards of the Mac and I worry this telegraphs that this kind of
shovelware is fine. This can establish a kind of "If it's good enough for
Apple..." precedent.

I also find it pretty hypocritical for Apple to constantly tell us they won't
ship a touch screen Mac because you can't make an OS that is good for both
touch and indirect input, but here they are providing a framework to dump
touch screen UI apps on the Mac for use with a mouse. Instead of a poor
unoptimized touch experience, we get left with a poor unoptimized mouse and
keyboard experience, precisely the kind of thing Apple have spent _years_
telling us that not putting a touch screen on the Mac would prevent.

That said, I can sympathize with the counter-arguments in favor of this. Mac
app development is nothing close to what it once was, perhaps this is the best
we can hope for.

~~~
andrewmcwatters
Yeah, well Steve Jobs called Galaxy S phones "Hummers," and I can't look
around an office without seeing people holding Range Rovers. So, there's that.

Turns out even though "you can't get your hand around it", people _did_ buy
that.

I think the real reason Macs won't have touchscreens is that Jony knows it'll
result in disgusting monitors. Can't have that now can we?

------
WalterBright
Fortunately, this isn't about the food. Phew! I love marzipan.

~~~
sbussard
Haha I also thought this was referring to the most delicious ingredient known
to man

~~~
tln
The only reason I clicked was to vigorously defend marzipan in all it's glory

~~~
em-bee
the only case to be made against marzipan is that there often isn't enough of
it.

------
petecox
> iOS app porting inherently creates bad Mac apps

Reassess in a couple of years when app porters have matured with the
technology. Gestures and pinch and zoom won't work with a mouse but the key
point is interfaces _designed_ for a form factor.

UWP on Windows mightn't be a great success but there's no reason a universal
toolkit can't serve both. c.f. Qt - a first class citizen on mobile (Sailfish)
and on desktop (KDE), while Plasma Active has real potential on postmarketOS.

On Android, where I am typing this message, a good number of apps designed for
tablet work surprisingly well on a desktop (Outlook, Apple Flinger, Hot Death,
Taskbar, iview, SBS on Demand, Supertuxkart to name a few). A bit more polish
for mouse in the form of tooltips, contextual menus, scroll wheels and menu
bars and it'd be a nice interface.

~~~
jimbo1qaz
Desktop KDE (and native-looking Qt apps) uses Qt Widgets, whereas mobile
basically uses Qt Quick. The GUI apis are completely separate (I'm not sure
how much is shared internally, or how similar the apis are).

~~~
petecox
Are you sure?

I thought Qt Widgets were deprecated by Plasma 5, which uses QML internally.

~~~
jimbo1qaz
The system update app, and the system settings left menu probably uses Qt
Quick. It has touch scrolling, fuzzily rendered text, terrible keyboard tab
support, etc. The rest of KDE 5 looks exactly like PyQt programs written in Qt
Widgets.

------
huebnerob
Lowering the effort bar for making Mac apps doesn't mean that every developer
is going to do the bare minimum, but it does mean that more developers will
find it economical to build natively. The point you're arguing is not good
apps vs. mediocre apps, it's mediocre apps vs. no app at all.

Frankly, there are many cross platform services I use where I would prefer a
straight Marzipan port from the iPad app over the electron psuedoapp approach
that's so pervasive these days.

~~~
giobox
While Electron is inferior in almost every regard, at least the UI might
actually make sense for Mouse and Keyboard manipulation.

Seeing touch sized click targets on HiDPI non-touch displays as one does with
the Marzipan approach is not great.

~~~
zozbot123
> Seeing touch sized click targets on HiDPI non-touch displays ...

That's always going to be a thing, as long as desktop environments lack a
_simple, foolproof_ way of switching system-wide between a "mouse/pointer
input preferred" and a "touch/swipe input preferred" mode. (Windows 10
actually does this fairly well; I don't know of any other systems that offer
the same thing, though.) It doesn't have to be a _huge_ issue if the touch-
friendly interface is well-designed. See GTK3, which has essentially switched
to "touch-friendly" widgets and layouts with the new major release. Some
people gripe about it, but at the end of the day it works fairly well - and at
the same time, it lays the groundwork for a wholly touch-based interface to
the Linux desktop.

~~~
giobox
> That's always going to be a thing

Except that Apple spent a decade telling us it won't be a thing, which is why
they never put a touch screen on a Mac. Until 2018 it had never been a thing.
Supposedly this is iOS's remit, and designing the entire OS for solely touch
(iOS) or solely mouse and keyboard (MacOS), they argue, is the better way
forward.

Your arguments are perfectly valid for many other computer platforms, where
mixed direct/indirect input exists. It has never existed on the Mac,
supposedly by design, until now when Marzipan has provided a path for these
touch UIs to ship on them. This is why it feels especially wrong on the Mac.

------
WalterBright
I wish people would stop naming products after common names and letters for
other things.

------
mrpippy
> macOS Mojave shipped with four native apps that Apple had ported over from
> iOS. These apps were clearly examples intended to incentivize third-party
> creators into using the new API.

This is not the case at all. 3rd parties can't (officially) use the new APIs
at all until next summer. I suspect (and very much hope) that the APIs and
these apps will look quite different in 6 months

------
lupinglade
Have to agree. This is pretty half-assed and seems useful for maybe just a few
edge case apps. In all other cases, it will really hurt the Mac user
experience.

------
tln
I wonder if electron apps brought the same fear in the author; and how he
views slack or vscode in the pantheon of Mac apps. Ok not slack. But vscode
compares very well to say xcode

~~~
giobox
Comparing VSCode to XCode is pretty unfair. XCode is a vastly more complex
application with many, many more features and requirements to support.

Conversely, it’s pretty likely an Electron version of XCode would run like
garbage, a native version of VSCode would run faster and consume much less
resources (memory, battery etc).

I don’t think it’s appropriate at all to argue VSCode somehow compares
favourably.

~~~
tln
I dunno, vscode is packed with features, and Xcode has almost always given me
a few minutes of beach ball cursor or crashes.

But the comparison should be about how mac-like the applications are. if
vscode or xcode are outliers, some other electron or Mac apps could be
compared.

------
mrunkel
What are the four apple Marzipan apps?

Ahh, found the answer: Home, News, Stocks and Voice Memos

------
dmix
If the apps are bad then people wont use them, so I don't see what the big
deal is. That's why there are reviews on app stores.

The benefit could potentially be thousands of very useful apps that are well
designed for desktop. Overtime the API and SDK's and libraries and best
practices, etc, will mature.

Responsive design has been a thing forever in web design. I don't see why
MacOS development can't adapt similarly. Ultimately two exclusive 'native'
apps might still be ideal, but not always for everyone who can't afford to. So
it's a lesser of evils type of situation.

