"I didn't have time to actually make or keep a budget, or learn anything about the topic, so I spent six months writing an app that is basically Mint, but slightly prettier, and worse." Don't ever change, tech dudes!
Well, I guess you can't tell for sure if it's worse than Mint before using it. If it's prettier (as you said) and its UI is more intuitive there's a chance it can be better, at least in some aspects.
I guess you're right, I didn't have time to make a budget but have some to design an app because by doing this I learned a lot when it comes to design, and after all I earn money by designing things. So it's a win-win
Right back atcha, bro; your willful ignorance of the topic or any other solution is, I would say, a focus of your piece.
Done:
[x] Identify a problem ("overpaid millennial techies don't keep track of their spending because they just can't be arsed")
[x] Waste a bunch of time shipping a mobile app six people will ever use
[x] Write self-important, poorly-copyedited Medium post
These are the most visible parts of the design process, but they won't get you success unless you're reeeeeally good in a room with some pretty rich, dumb motherfuckers. (I am made to understand this is getting harder and harder lately.)
Not done:
[ ] Hard stuff?
[ ] Research design process: what else happens??? (<- this sounds hard)
The difficult, meaningful stuff no one really seems to give much of a shit about anymore. Except, of course, the people making good and interesting work that will actually matter a few years from now, and not just destroy a bunch of wealth and effort. But they don't write Medium posts.
I've noticed the same thing with audio amplifiers. I just moved into a relatively small apartment, and have been shopping around for a compact stereo amplifier that apparently doesn't exist—good-sounding audio seems to exist in this weird market niche where the hugeness of the black metal box that used to house vacuum tubes and now is just ICs and empty space is a feature, not a bug.
I think there is still a need for higher quality audio hardware to be larger. My amplifier isn't that old (certainly not old enough for vacuum tubes) and I can assure you, there is not a lot of empty space. Power necessitates large transformers and capacitors, and produces more heat, all of which would be challenging in reducing size.
That said, while there aren't many high quality amplifiers with a smaller footprint, there are a few on the market much reduced in height that are still good quality.
The same goes for speakers. Generally quality requires size (although a lot of that is due to the increased volume that is expected to come with expense), but there are a few neat tricks to make small ones that buck the trend.
before changing directories, it's less of an issue. And `rm -fr /' is less likely than `rm -fr ~', since most people don't need root access to call `ls'.
But still, I don't add '.' to my path because the only time I directly reference files in my current directory, it's because of a Zsh suffix alias.
[Flash] appears to under-perform on every platform I have except Windows (Windows in VMware + Flash is better than native Mac Flash, I swear!).
Flash has been an albatross for Mac users for a decade. It has performed terribly, crashed our browsers, and with the rise of YouTube &co. forced us to use it to watch videos via a hilarious, incredible, inefficient hack instead of a real native video player.
We are really (and understandably) happy to get rid of it, especially if that means we get to skip the worst kinds of ads and online videos don't churn the CPU anymore.
For all its usefulness, Flash just isn't worth the hassle for Mac users, and it's largely Adobe's fault that we find this to be the case.
Dave might be right in broad strokes, but the post is very muddy on what it would mean for "iOS apps" to run on the MacOS.
Fundamentally, it would be pretty straightforward for Apple to allow iOS apps to be easier to port to the MacOS: bringing some of the UIKit APIs to desktop Cocoa would make things very much easier. As it is, anything that touches images or the user interface has essentially zero overlap between the desktop and mobile APIs. Very frustrating.
However, the speculation about MacOS on the Air being a "compatibility layer" is utterly ludicrous and unfounded. A quick peek inside /System/Library/Frameworks will indicate that the build of 10.6.4 that runs on the Air uses exactly the same set of frameworks that Apple has built up for the MacOS as any other traditional computer they sell.
While the brief preview of Lion given the other week indicates that there will be significant cross-pollenation between desktop and mobile OSes for Apple, in both user interface and (one assumes) APIs, it's hard to exaggerate how off-base this particular item of speculation is, in the right-here and right-now.
I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops, but as any iOS developer can tell you, even porting an app from the iPhone to the iPad is hardly a set-it-and-forget-it affair. Winer snarks about the multitouch trackpad at the end of this article, but he's just as wrong about it now as he was when he first said it.
The iPhone is a fundamentally different user experience from the iPad is a fundamentally different user experience from the MacBook Air, even if 10.6.5 + Mac App Store includes all of UIKit.
I would be unsurprised to see a third architecture added to "Universal" iOS apps to allow them to be run on Lion desktops
Disclaimer: I haven't read the post; I can't because the site isn't loading for me. Instead, I'm replying to the OP.
I would be very surprised to see this. I contribute to Colloquy — An IRC client available for Mac OS X and iOS (iPhone and iPad). Having three separate UIs aside, the shared code between the projects doesn't go through the same build steps. It cant, because iOS doesn't allow third party dynamic frameworks to be loaded; they have to use a static library instead.
In the case of Angry Birds, if you take the .ipa from iTunes and unzip it and then run otool -l on the binary, you can look at the frameworks it uses.
The iOS-specific frameworks it uses are: UIKit, OpenGLES, MediaPlayer and GameKit. GameKit could likely be ported fairly easily. MediaPlayer with a bit of work, could be mapped to QTKit. OpenGL to OpenGLES, I can't say; I don't know anything about either. And UIKit? Mac OS X has to run on Mac Pro's and iMac's as well. Which may or may not have a multitouch device attached. UIKit would be a kludge with multitouch trackpads, and downright useless without one all together.
All very good points, and I think we agree on the major bits. Reading over my last post I think I might have been unclear on the main takeaway: desktop apps are fundamentally different from mobile apps.
If Apple lets us write apps that run on both platforms, I would expect the desktop versions to include substantially different resources and have fairly divergent codebases: different nibs, different build processes (perhaps with the disparate binaries packaged into one .app bundle), different interaction metaphors etc.
UIKit would be a kludge with multitouch trackpads, and downright useless without one all together.
This is largely true, but there's more to UIKit than touchesBegan:withEvent:. In particular, UIKit's view controllers/navigation controllers/table views could work quite well on OS X (and looking at iLife '09 and the preview of full-screen apps in Lion, this seems quite likely). Further, more iPhone apps use these classes than do advanced multitouch.
Again, this is not to say that writing one app that could conceivably run on both platforms will be at all easy; I still think the OP is way off the mark about that. But it's not unthinkable.
I have vmWare on my Mac desktop, running XP. If you look in the Windows folder you'll see everything you'd expect to see in a Windows installation. It is a Windows installation. That's the sense that I meant to raise the question for thinking purposes about which is the compatibility box. I meant to say you could see it either way. And my guess is that the strategic thinking at Apple is that the box is contianing the Mac software not the IOS software.
That's based on watching Apple evolve stuff, very slowly and carefully, since 1997. There was even some of this kind of thinking in the move from the Apple II to the Apple III, back in 1981!
I'm not looking at this one year at a time, nor are the people at Apple. They're thinking of a transition that might go for ten or fifteen years.
The neat thing about iOS and MacOS, compared to Windows in VMWare, is that iOS apps are never 'emulated' on MacOS—they're 'simulated'. In fact, I'd wager that during its development, Angry Birds was run on a Mac far more often than on an iOS device. The iPhone Simulator is just a wrapper for x86 binaries linked against iOS frameworks.
If this is actually in Apple's plans, running iOS apps on MacOS wouldn't be much harder than making these frameworks first-class citizens... plus a whole lot of work reconciling the fundamentally different interaction, document, window, and application models. (Guess which of those 80 and which is 20. :)
The thing is, _every_ cocoa mac app currently uses the old UI classes, and it might be difficult to get existing mac developers to move to UIKit.
Typical Apple style is probably to move the UIKit stuff in for a release, then deprecate the old stuff in the next release (e.g. powerpc on snow leopard). Remember the Office 2010 apps that were being praised at the Apple event? Bam, deprecating the old UI APIs means that Microsoft has to re-code all of that to get their apps working again. And Adobe, not to mention all of Apple's apps, both internal and external. And devs can't target multiple versions of OS X.
The alternative that Apple is probably going to choose is to make the old UI stuff the new carbon - supported for a while, but not getting any updates. The real people this would hurt are, again big corporations, but some of the open-source projects who could spend their time on new features but are instead spending their time re-coding for the new UIKit APIs.
For some reason it always astonishes me how incredibly reactionary geeks are. We're supposed to be the neophiles.
Listen: for the first time in history, ordinary people are actually using computers, every day, in their real lives, and we're kicking and screaming as hard as we can against the systems that have made that the case.
The future is different from the past. The coders who are empowering creativity on iOS (and similar devices) aren't the ones whining about how hard it is. Get over your ridiculous nostalgia, stop bitching, and write BASIC for the 21st century.
Disk images are one of the most confusing things about day-to-day Mac OS X use, no question. The next time you're at a relatively non-technical friend's house, apple-click on Firefox or Chrome in their Dock. Dollars to donuts, it resides on a disk image.
Apple got rid of disks, why not get rid of the images too?
Pedantry: in iTunes the song plays when you hit Return; Enter will rename. Still different from the Finder (where Return renames), but not quite the same thing.
