vitovito

Yes, you may be contractually forbidden from doing such work.

You need to have a lawyer review the IP assignment clauses in whatever you signed. It may be that there is no such thing as "outside of my job." They may own everything you do regardless of when or how you do it, which means their policies apply for everything, all the time.

Even a reasonable IP assignment, that only assigns ownership to the company of work that is directly related to your responsibilities, might conflict, since you'd be making an open source project to help with your responsibilities.

Talk with a lawyer.

Probably not in the way you imagine it happening.

First, you're probably not looking for open-ended critique. There are probably a limited number of things you're open to and capable of changing. They're probably mostly superficial things at best; you're probably not going to pay what it would actually cost for someone to analyze e.g. an onboarding flow.

Most designers deal with people who only want superficial changes all day long for their day jobs; they don't also do that for fun or beer money.

Second, a designer doesn't know anything about your users or your vertical. The most a designer could do is suggest things for you to test. You still have to build them out and test them.

If you're like most startups, you don't have infrastructure or traffic enough to do this well, to measure a baseline beforehand and change after the fact, etc.

Third, wherever you're located, there are probably local design meetups and professional chapters. They probably have happy hours and office hours. If you're really interested in improvement, you could follow my suggestions from this thread: https://news.ycombinator.com/item?id=8756258 pasted below:

Put together your customer lists. Make sure you understand their demographics and their usage patterns and why they purchased and what they were considering instead. Make sure you have ways to contact them for research interviews and if it's possible to go on-site to see them use your product live. Document how your competitors present and discuss their products.

Then, pick something. One small thing. A landing page. A particular form. A headline. Copy for a Google Adwords ad. Something you can measure your current performance on, and measure a change to afterwards. If you're not high-volume, this might be harder to find than you think, but go through the exercise of figuring out what you can collect enough data on now, and what can wait to change until you can measure it later (or what you don't care about measuring).

Then, you can take that one thing to a designer and say, "I'm looking to experiment with different changes to <X>. What are some things you think might be interesting to try? Anything goes."

You're not asking them to do any work. You're not asking them to stake their reputation on the line. Your language ("experiment," "different changes (plural)," "interesting," "try," "anything goes") all says you're willing to respect their time and level of engagement and also that you're prepared to handle their advice properly, that you're not looking for a silver bullet, you're looking for all of the lead bullets.

Say you ask for help with a landing page. A designer might suggest some copy or visual design tweaks for clarity (specific changes), but also suggest you test different headlines (without providing any), and also changing your format from short form to long form or vice versa (definitely without providing any content to you, but maybe they would be interested enough to sketch out some varied layouts). These are all great ideas. You should read up on A/B testing and test all of them in isolation, and also all together. You should test big dramatic changes even more frequently than you test small copy changes, because you don't want to be stuck looking for a local maximum. A UX person might also suggest ways to find out other things to test, research questions to ask, and suggest books or other resources so you can collect that data well.

A startup that came to office hours that well-prepared would basically almost not need design help at all.

How is this even a draft RFC?

It's like the author forgot about XML and the failures of its draconian error handling and decided to do it all over again.

It ignores the reality of implementations, and of commercial software development in general. Implementations aren't written in an ivory tower with an endowment for long-term maintenance, they're written in ten days against hand-wavy business requirements at companies that no longer exist in their original form. Users will go elsewhere, to software which uses formats and protocols which don't have draconian error handling.

Wishing it were another way won't make it so, it'll just give you XML all over again.

Some discussions from the time, none of whose arguments this RFC addresses:

https://web.archive.org/web/20081210125015/http://diveintoma...

http://www.aaronsw.com/weblog/001025

https://web.archive.org/web/20090416022813/http://diveintoma...

https://web.archive.org/web/20090309211058/http://diveintoma...

The USPS considered it at least a couple of times. https://www.bloomberg.com/features/2016-usps-email/ discusses their E-COM efforts in the 80s, and individual email addresses in the 90s. They were finally legally restricted to physical delivery in 2006.

At that point, it might be too late. It's hard to reset expectations in the middle of a project that's already gone off the rails, short of pulling the team and replacing them with a client relations person, hence my advice.

If OP is "just" an engineer, I feel like they've still neglected their responsibilities as a consultant, and I think all my advice stands, because it means they didn't talk with their manager about this project, they just went in blind, full of assumptions.

At the consulting company I mentioned, everyone had to go through consulting craft 101, everyone had to learn how to be "client-facing," because at any point someone from the client might want you to add something out-of-scope that should be just five minutes and you might want to do it to be nice and make friends.

I have absolutely had loud, difficult arguments with technical leads and project managers who did not do all the due diligence necessary to inform my scope of work. That's my responsibility to make sure I'm able to execute, I'm set up for success, and the project doesn't fail.

I don't see a difficult client, I see a consultant who didn't ask the right questions before taking the job and isn't seeing things from their client's point of view now that they have it.

Why don't they show up to standup? Why aren't your emails a priority to them? Why was a demo to the CTO necessary or desired? Why did they leave you out? Why was that flow important to them? Why did they discuss something out-of-scope?

I only see your perspective. If you don't know the answers to these questions, why not?

Advice isn't going to help; you need a relationship manager. You probably need to bring someone in to get face time with this person, and handle them on an ongoing basis, again probably in person every time. It's going to get expensive. You're probably not going to make as much money on this contract as you expected as a result. This isn't a technical problem to be learned from and fixed; this is an interpersonal problem with someone who works and thinks differently than you, who is also unfortunately holding the purse strings.

The most valuable thing I learned working in consulting wasn't how to be a better designer or developer, it was how to handle relationships. I learned that the next time I went out on my own, I'd hire a business and relationship manager, and I would absolutely pay them 50% or even 60% of my earnings, because that is the "real" work of consulting.

A relationship manager will give you a list of signs that you shouldn't have taken this job in the first place. A relationship manager would have specified that this person's attendance in standup is either mandatory (and therefore in the contract) or not required (which means they wouldn't have even been invited). A relationship manager would probably have established up front how this person likes to work, and that probably means in-person, and would never have sent an email, and instead had lots of meetings. A relationship manager would have made sure you kept control of the demonstrations, so off-message presentations couldn't have happened, and would have made sure that out-of-scope things either didn't come up, or were quickly addressed by understanding why they came up.

Your takeaway from this will be how to better vet potential clients, so you can either not take their money, or add in the cost of relationship management to their contract. You'll also learn to write better contracts, that firmly establish the participation required, including penalties up to and including the termination of the contract with full payment and no deliverable, should the client violate their expected level of participation.

I think this is what's known as a "stored value card," whether it's like a traditional gift card with a number and signature stored on a magnetic strip, or a smart card-based system, where a tamper-resistant cryptographic chip (just like the one in your SIM card) stores and manages a value on it.

https://en.wikipedia.org/wiki/Stored-value_card

https://www.fiscal.treasury.gov/fsservices/gov/pmt/storedVal...

I'm glad you recognize that there isn't a path yet; many people don't!

The short answer today is: you have to ramp up on creating content in 3D engines. If you can't build out all of the content yourself, you can't effectively work. That means, to some degree, creating original 2D and 3D assets. The #1 thing Microsoft tells designers who want to work with Hololens, is learn Unity and learn the workflow to deploy Unity content into a Hololens yourself, without developer/engineer assistance. (UnrealEngine4 is the other major option.)

As a web-based designer, tools like React VR and A-Frame might be useful, but your tooling there is always going to be a distant second to the established 3D players, and so your content quality will also lag behind.

YC's guide: https://blog.ycombinator.com/how-to-get-into-vr/

Some other Medium post that wasn't bad: https://blog.prototypr.io/designing-for-vr-a-beginners-guide...

As far as using real hardware, your AR options are kind of limited if you can't afford a Hololens. You could try and find a second-hand CastAR Kickstarter developer prototype headset. You could maybe fake something with the Vive's front-facing camera or the Leap Motion as a camera on an Oculus Rift. You could cobble together a Pepper's Ghost-style Google Cardboard-alike, like Aryzon: https://www.kickstarter.com/projects/aryzon/aryzon-3d-augmen... or this DIY version: http://www.instructables.com/id/Cardboard-Hololens/

But, mostly, of course, you have to have something to build, and blog posts won't help you there! There isn't a curriculum of standard AR/VR exercises like there basically is for web-based design (build a landing page, build a CMS admin interface, build a shopping cart, etc.).

As a beginner in programming, learning programming itself is supposed to be what's exciting to do. You're coming to know a whole new way of thinking and doing.

There have been an enormous amount of beginners before you; of course all the things beginners can accomplish already exist. Many have turned into experts before you, also; of course many of the things only experts can accomplish already exist.

But, it's all new to you. As a beginner, your job isn't to create, it's to learn and improve, to understand. Meaningful creation might come later. You can't do that if you never do anything at all. You have to start by learning what's possible, and that means doing things that have already been done, for yourself.

While the Internet Archive sells and supports their scanning hardware, and there are community plans if you wanted to build your own, since you don't have a budget and don't want to do it yourself, perhaps the National Library of Australia's "Trove" project is a better avenue:

http://trove.nla.gov.au

They're a partner with IA as part of the Open Content Alliance, and they provide complete end-to-end non-destructive scanning and hosting services through the Trove site and software:

http://help.nla.gov.au/trove/digitisation-partner-guidelines

150 magazines * 100 pages * AU$1.65 for a "journal" page is AUD$24,750, plus whatever it will cost you to "negotiate and document reproduction permission with copyright owners."

(For that price you alternatively could buy the Internet Archive's scanner, but you'd still need labor to operate it. Or, for US$1750 you could get the parts for a DIY book scanner, and then use the rest of the money to hire people to build and operate it, which might cost less, maybe. The results wouldn't be guaranteed, however, as they would be through IA or Trove, and you'd still need to host it and the content somewhere.)

There's still a few unanswered questions; the answers make a difference.

That said, the Internet Archive scans and preserves material for US$0.10/page, including storing it in one of their warehouses. 150 100-page magazines would be, uh, a US$1500 donation.

For that, you'd get ~300dpi scans (actually photographs) of each page, taken with a DSLR without damaging the magazine.

That's about the page count and what I donated to preserve the out-of-print works of Jan V. White: http://www.janvwhite.org

To get higher resolution scans, generally you either need even more expensive, larger format digital cameras (41MP gets you 8.5x11 at 600dpi), or multiple cameras stitching the photographs together, or to do destructive scanning, cutting the binding and feeding the pages through a high-resolution sheet-fed or flatbed scanner (don't do this).

Snapchat uses Wifi Direct to transfer HD recordings off their Spectacles.

Perhaps you mean you'd like to see other apps with source available that perform similar mesh networking?

Not so sure about "epic task," mostly just "labor-intensive" task, coming from someone who's built a few book scanners and preserved material in a few different ways.

Lots of established practices in this area, but it all depends on time, budget, and level of effort. Are you looking to do it yourself? Do you have a budget? Do you need to do it on-site or can you ship them somewhere? Are you expecting to preserve the physical magazines, or do you expect to destroy them in the process?

I had a verbatim transcript already, and I used CMU Sphinx to do the alignment between that and the recording.

With raw audio only, I'd probably use a transcription service that provides timings, or software like Trint to do machine learning first, and then clean up by hand, like you did.

The software I wrote to handle the playback is here: https://github.com/vitorio/hyperaudio-lite

I don't see any audio controls, or audio download progress, in either Safari, Chrome, or Firefox. Looks like a syntax error, there's some HTML in a Javascript file.

Conceptually, since I can't try it, it reminds me a bit of hyperaudio. Have you seen http://hyperaud.io?

I also did a hypertranscript similar to this here: http://vitor.io/uxr101 Click on any word to scrub to it, or click in whitespace to toggle play/pause.

I bought a similar Qwerkywriter after their successful Kickstarter in 2014: https://www.qwerkywriter.com

​It makes a lot of noise, although obviously not as much as a typewriter would. It has an enormous amount of key travel, and the spacing between keys is huge compared to modern keyboards. The aluminum body makes it solid and heavy, although metal keycaps would have been nicer than plastic ones.

If you like enjoy typing on a typewriter, it's a related experience. If you have extensive mechanical typewriter experience and really want the full throw and noise, you probably want conversion kit instead: https://www.usbtypewriter.com/#gs.9tDxQ0Q

I have no idea, I'm not either of those types of people for the current VR/AR/MR industry. And, even if I were, whatever I might say is not certain to be useful to you.

Normally, I'd recommend you interview people working in the space to understand what problems they're encountering now, and what they expect to run up against next, but when they're inventing as they go, by definition, they don't (and can't!) know.

They could tell you their current problem(s), but neither you nor they know if that's a general-case problem, or a problem specific to their implementation. Plus, they'll solve it in parallel before you, because they have the compounded knowledge of all their work leading up to it.

Only the people actually working on the problems know what those problems are, and they don't have time to stop and bring you up to speed. You have to catch up, or at least show you're on the way on your own.

The job listings seem to support this:

Apple wants either a PhD, which means having published papers advancing the field; or industry experience delivering products, which means having discovered problems and then solved them for real users and getting paid for them, end-to-end.

Snap wants a Master or PhD, or "experience implementing, verifying, and optimizing," which is just short of being responsible for shipping a product.

Magic Leap is an internship, but they want "Demonstrated experience," aka having built something yourself.

In this, you can't be a generalist, up for solving any problem. I'm sure you're entirely capable of that, but the requirement is also that you can figure out what the problems are and will be, on your own. In a new industry, there aren't paths to follow, everyone's still cutting down brush.

They're not publishing most of their work, so you have no idea what's solved, and even if they were, I think it's generally accepted that a published paper (or launched product) is a few years behind what's currently being tried in a lab.

You will probably inevitably be redoing someone else's work, but you won't learn that for months or years.

I'm not sure there's any advice I could give except to pick a problem domain, pick a use case, learn all the component pieces of that problem, make new and different tradeoffs, and figure out what's unsolved for the choices you made.

I'm not in the current AR/MR/VR industry, but I have friends and colleagues who are, and I worked in VR last time it was a thing.

I'd guess you're missing one or more of: (a) serious EE/ME experience, (b) having contributed to computer vision/graphics instead of just understanding the current state of the art and/or tooling, and/or (c) having designed and built AR/MR/VR hardware and software systems from scratch instead of building apps for existing systems or using existing tooling.

At a company that is inventing something new, the most valuable, sought-after hires are of people who invent and advance the company's work; and people who can interface between engineering and content.

The former means people who invent and write algorithms for OpenCV, not people who simply use OpenCV. Or having built AR hardware and software in combination, and therefore have a deep, practical understanding of the tradeoffs in different generations of hardware and different methods of projection, etc., rather than having only built apps for existing AR toolkits or platforms.

The latter means software developers who can also work with the hardware. They may not be required to design a circuit board or engineer some optics, but they understand the operation of the hardware, can fix it if it breaks, can diagnose hardware problems and provide the sort of hardware bug reports every software developer wishes an end-user could provide, etc.

(An example of this would be the technical artist in video game studios. They're a respected, senior artist [so they can make actual art, and so their processes to do so are reasonable and representative] who can also program, and either creates tools for artists, or is the interface between the artists and the tool developers.)

If you aren't one or the other, then you're a step removed from where the company is at: inventing new things. They don't have the time or manpower to hold your hand. You're stuck only being able to build for the things that already exist, not helping them advance.

It's why Microsoft's #1 recommendation for non-technical designers who want to get into HoloLens work is to become technical enough to be proficient in Unity, if not the entire Windows 10 development toolchain. If they aren't self-sufficient enough to be able to get all of their work onto a device on their own, HoloLens isn't ready for them yet. It's not plug-and-play, everyone involved needs to be able to wear all the hats.

If you can't show that you're already inventing new things yourself; or that you have a practical, working knowledge of the entire system, the kind that comes with having built something from scratch; then there may not be a place for you yet.

The original SDL support was a JavaScript implementation of just enough of 1.x to get things compiling.

SDL2 cross-compiles to JavaScript properly and should be used by most things now.

https://papercutsoftware.github.io/teleportme/ was an open-source-ish solution I came across recently (built on FaceTime), but I haven't tried it. Seems like they're making similar design decisions as you.

Have you looked at some of the prior work in this area to see things that teams wanted?

http://danielodio.com/project-stargate-always-on-skype-video...

http://danielodio.com/remote-always-on-connecting-our-office...

Perch is a startup that's mentioned a lot in the comments, and I trialled it and it was pretty nice, but it just shut down last month. Perhaps their "customer stories" or "blog" sections have enough detail about the app's features, or perhaps the Internet Archive has a full copy of their old site:

https://perch.co/customer-stories/

https://perch.co/blog/

https://web.archive.org/web/20160911054842/http://www.perch....

Bret Victor thought about this, this time last year: http://worrydream.com/ClimateChange/

"What can a technologist do about climate change?" to answer the question, "How do you think the tech community (startup community, or any community) can contribute to tech and/or policy solutions on a global scale?"

http://danielodio.com/project-stargate-always-on-skype-video... is the first popular article I can recall about this.

http://danielodio.com/remote-always-on-connecting-our-office... is a followup that mentions that the always-on connections would have problems.

Perch is a startup that's mentioned a lot in the comments, and I trialled it and it was pretty nice, but it just shut down last month: https://perch.co/blog/goodbye-perch/

If you have a couple of Macs to spare, https://papercutsoftware.github.io/teleportme/ looks interesting, but I haven't tried it myself.

There will be people reading this who have never used a Terminal, or typed at a command line, or called directories anything other than "folders".

There will be people reading this who have never installed anything that wasn't from an App Store.

There will be people reading this who have never heard of source control, branches, repos, or any of the other jargon in your document.

I think the number two thing project maintainers need to do is to stop making assumptions about the background and experience level of their potential contributors; or, if they do, to admit and outline them.

I write more about this here: http://opendesign.foundation/articles/import-designers/

I wrote up my initial experiences here: http://vitor.io/razer-blade-stealth-core-gtx-1080-12h

Works pretty well, no insurmountable issues. I haven't done any 3D engine-related dev on it yet, but am not expecting issues.

The thing about doing this kind of work is you have one sort of explanation in mind as you do it, and like any software, you work until you're there and then you call it done. They're not designed and built with every possible form of accessibility and exposition in mind. It's entirely likely no-one had previously considered doing a narration.

That said, there's also zero advanced tooling to create and edit synced audio, and nearly zero tooling for playback. I wrote my own for http://vitor.io/uxr101, available here: https://github.com/vitorio/hyperaudio-lite

#jsmess on EFnet IRC if you'd like to talk with the developers

UX person here. I can do the spectrum of work from BRD and research through to wireframes and prototypes, but I stop before visual design.

You've enough detail in here that it's probably not entirely you, but rather your organization. The org has probably hired artists not designers and doesn't know how to make them properly accountable.

The simplest difference between an artist and a designer is who they work for. An artist works for themselves, a designer works for a business goal. An artist wants to be personally satisfied, a designer has metrics.

I've never met an artist I would trust to also do research or usability design, however, so wanting to push them be UX people instead of artists is probably not going to work.

However, you might be able to exert pressure by giving them design constraints.

A visual designer isn't designing a UI for themselves, they're designing a UI for the users of their application, so their business goals are things like user satisfaction, user comprehension, and user efficiency. Do the users like the look and feel (measured with things like desirability tests)? Do the users understand what they are looking at and finding what they need on each screen (measured with comprehension tests)? Do the users get their activities done as fast or ergonomic as possible (measured with usability tests)?

The last one you can directly influence on the engineering side. Chapter four of _The Humane Interface_ explains how to quantify usability. You can literally measure the usability of a UI and establish standards for performance, just like you establish standards for your code's performance. You can mathematically determine the minimum amount of input required to accomplish a task and measure the UI against that, with goals of improving the UI a certain amount over time. You could create test suites that measure a click path to see if a UI change improves or regresses it.

Putting these design constraints in place and then making the designers responsible for hitting them are a good way to see whether they're really designers, or just artists.

Any spectrum recordings would almost be guaranteed to include copyrighted content, and in the US distributing those recordings would fall afoul of the DMCA.

From my notes on a radio archiving project I'm doing:

> Could you record the entire radio spectrum and extract stations and broadcasts later?

> In the USA, the AM radio band is 540-1710 kHz, a spread of 1170 kHZ,

> http://rtl-sdr.better-than.tv/?page_id=237 states that spectrum recordings are also a function of how many samples per second you choose to record:

> 2.8msps - 44.8mbps = 5.6 MB/sec.

> 2msps - 32mbps = 4 MB/sec.

> 1msps - 16mbps 2 MB/sec.

> http://www.myradiobase.de/perseus/ has sample files. 3.5 minutes is ~360MB. 60 seconds of 1500 kHZ is a gig. All too much. 24 hours at 1MB/min is 1.5GB, but 17MB/sec. is 1.4TB. Spectrum recordings are out.