61–70 of 124 posts
http://www.onebigmenu.com I'm working on this site right now, and I understand your concerns because I feel them myself. I'm hoping I can bridge the gap between dining and diner. :) (Please excuse the design, since I'm the only developer :P)
One last thing, If any developers want to join forces, that would be cool too :)
One reason for menus in PDF is because the menus may change frequently, and a PDF is easy to create from their actual print menus. It doesn't seem like a big deal to update both an InDesign layout and a website, but if different people do those two things, then it's quite likely a mistake will be made, so it's smart just to use the already proofed version.
I also deal with this while keeping my resume updated and tweaked. I have an HTML, PDF, and MS Word format. I use a print CSS sytle sheet on my homepage ( http://ronnie.me ) so that I can print it to PDF for the PDF version and manually create the Word version. Very tedious.
Because restaurant owners are barely figuring out what email is. How often do you go to restaurant websites vs. actual restaurants (not including Yelp or Google maps)? Truth is, they just don't matter. The cost of creating a website, even a $500 design over a CMS doesn't justify the cost. Also, a small business restaurant owner won't know how to operate a CMS. They just figured out email, remember? Worse, is that web…
Someone needs to make tumblr for front page/business card websites.
1. Restaurants have tiny margins. 7% profit is doing well, and dishing out $1k or more for what they perceive to be a Yellow Pages ad is unthinkable for a brick and mortar store.
2. Restaurant people are techno-iliterates (in general). I set up a Google Apps account so the managers could communicate with branded email, share documents, schedules, etc, and had to give more than a couple training sessions on these basic tools.
3. They don't consider it something to be 'involved' with. I've tried to press the point of building a presence through social networks, etc, but they can't wrap their heads around it. To them, you should pay someone (as little as possible) for it and it does it's job.
4. They explicitly ask for the faux pas. Owner asked me to take down the "outdated announcement" that we'll be having an event, since it was from last month. This is on the blog portion of the site. Owner asked me to upload the rest of the photos from an event (at least a hundred), even though the entire album is on Facebook, even though I explained no one in the world is going to care enough to flip through hundreds of jell-o wrestling photos on the news page of some restaurant's website. Owner asked for a photo background versus the subtle textured one I had designed the site with.
In the end, trying to teach them what emails is, arguing over design elements and explaining how people will use the site isn't worth it because they are going to be more work and less money than just about any other business owner. Slap something together and collect your $500.
I think there are a few things here that cause this: a) You're going against the worst kind of incumbent- the 15 year old nephew or kid next door. He's cheaper, good enough, and "trusted". He is competition that exists a million times over. b) Even if your system is better, they just can't be bothered to even get a good demo. You definitely need to build something so usable and good it's frightening, but good luck ge…
Because restaurant owners are barely figuring out what email is. How often do you go to restaurant websites vs. actual restaurants (not including Yelp or Google maps)? Truth is, they just don't matter. The cost of creating a website, even a $500 design over a CMS doesn't justify the cost. Also, a small business restaurant owner won't know how to operate a CMS. They just figured out email, remember? Worse, is that web…
"The cost of creating a website, even a $500 design over a CMS doesn't justify the cost." The question I guess is why restaurant owners spend money having flash monstrosities built when most users -- especially those on mobile devices, which is a big use-case for restaurant websites -- would rather see plain-jane HTML with an address, phone number, and menu. "The nephew of some restaurant owner finally convinces him…
I have a job at a web agency now and doing anything better than what's there simply wouldn't make since.
Earlier quoted context omitted.
I also deal with this while keeping my resume updated and tweaked. I have an HTML, PDF, and MS Word format. I use a print CSS sytle sheet on my homepage ( http://ronnie.me ) so that I can print it to PDF for the PDF version and manually create the Word version. Very tedious.
Ugh. Just learn LaTeX and write once.
I'd like to present some work which I think is good for a change (there are a lot of bad examples on here)
So here we go
http://www.brasseriegerard.co.uk
Some of our older ones
The most visited pages on our busiest sites are
1. Offers and vouchers
2. Locations
3. Menus
so it is really important to do those well.
Also we've recently launched a product that allows anyone with a website the ability to have a content managed mobile site set up and working in no time.
The product is called http://www.pocketdiner.co.uk
Any feedback or comments are welcome
Because restaurant owners are barely figuring out what email is. How often do you go to restaurant websites vs. actual restaurants (not including Yelp or Google maps)? Truth is, they just don't matter. The cost of creating a website, even a $500 design over a CMS doesn't justify the cost. Also, a small business restaurant owner won't know how to operate a CMS. They just figured out email, remember? Worse, is that web…
"The cost of creating a website, even a $500 design over a CMS doesn't justify the cost." The question I guess is why restaurant owners spend money having flash monstrosities built when most users -- especially those on mobile devices, which is a big use-case for restaurant websites -- would rather see plain-jane HTML with an address, phone number, and menu. "The nephew of some restaurant owner finally convinces him…