The Case Against Marzipan(uluroospeaks.com)
uluroospeaks.com
The Case Against Marzipan
https://uluroospeaks.com/articles/the-case-against-marzipan.php
28 comments
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?
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?
Fortunately, this isn't about the food. Phew! I love marzipan.
I was actually thinking about the Homestar Runner character. She is pretty bad.
As an antimarzipanner I was hoping to learn that its production harms the oceans or something along those lines.
i thought maybe it is something about cases of bitter almonds used to produce poisonous marzipan.
I thought it was about the hydrogen cyanide that marzipan contains in small amounts...
> 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.
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.
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).
Are you sure?
I thought Qt Widgets were deprecated by Plasma 5, which uses QML internally.
I thought Qt Widgets were deprecated by Plasma 5, which uses QML internally.
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.
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.
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.
Honestly, I disagree. The only Marzipan apps I’ve used so far are Apple’s built-in ones, and maybe things will get better because this is the early days, but they’re gag-inducingly bad. I honestly much prefer well-made Electron apps like VSCode and I’d take that any day if we can’t have good native apps.
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.
Seeing touch sized click targets on HiDPI non-touch displays as one does with the Marzipan approach is not great.
> 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.
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.
> 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.
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.
I wish people would stop naming products after common names and letters for other things.
[deleted]
> 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
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
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.
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
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.
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.
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.
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.
What are the four apple Marzipan apps?
Ahh, found the answer: Home, News, Stocks and Voice Memos
Ahh, found the answer: Home, News, Stocks and Voice Memos
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.
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.
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.