In winter: comfy slippers, maybe some warm socks if needed for warmth
Rest of the year, if I'm on my own: either nothing or maybe slippers
Rest of the year, with company: regular socks. I have roughly 10 identical pairs of socks, so that matching them is easy.
The edit is where most of the insight is on that page, and the reader comments on it are the most entertaining part. Quite a lot of the authors list seem to be things that are useful to discussions, albeit by virtue of helping newer users be up to speed with idioms that long term users take for granted.
Opt-in is generally more fair than opt-out, but in this instance it makes sense - they are not checking personal property, they are checking publicly facing webservers. They are not doing it for the server owners benefit, they are doing it to help keep people secure. Servers that aren't being patched properly are exactly the servers that are a security issue waiting to happen, that such a security force should be identifying and telling to buck their ideas up.
I suppose the differences in how those two equivalent departments approach this, likely come from national mindset differences, and the political differences they cause. At least it seems reasonable to me: that in Washington people might all agree that the right to decide if you are tested is more important than finding insecure webservers, whilst in London people might well all agree on the opposite.
I built a web-app MVP which is basically a QR menu app, as a web-app with URLs for each menu in the format webappDomain/RestaurantName, for example my demo is at tearounder.app/TheLoremIpsum
My MVP solves quite a few of the grumbles people mention, and other grumbles either dictate the sort of venues that shouldn't adopt this tech, or show why this tech should always be as well as traditional service not "instead of". (There are also some grumbles that require more development to iron out)
Stuff my MVP does that solve grumbles mentioned in this thread:
- simple URL format means you can use the URL rather than scan a QR code. If the restaurant name is long, a shorter version of the name should be used for good UX. I see QR codes that point to those URLs, as a good and easy option to provide for those people who now expect a QR code, but not the main way to access the menu.
- web based means no need to install an app (I have also met some of the basic requirements for a "Progressive Web App" so some browsers will let you save it to your device once you are on the website if you want)
- I keep file-sizes low, and put thought and effort into making it load and continue functioning smoothly even over slow and patchy internet connections. There are some things I could do to improve performance and smoothness on poor connections, particularly during building up your order, but it was easy to make it so that you can browse a menu to your hearts content even if your connection drops completely right after page load. Right now data for entire menu comes over at page load as JSON (that was created when restaurant last changed their menu), all UI up to placing order is handled in one page via client side JS, then as you add items to your order ajax calls add those items to a WooCommerce cart and tapping order sends you to a WordPress/WooCommerce checkout screen. Extra dev time to make a buffered version of that system, would get the connection need down to just the pageload and checkout/pay, but with the basic setup I have right now there is also need for a connection each time you add an item. The MVP setup would also require restaurants to have their woocommerce orders page up on some device behind the bar, which is not a great UI for their needs - so a "full" version of the web-app would need a custom page, and only use WooCommerce as a back-end if that made sense for that restaurant.
The headline on this post is misleading. The text seems accurate, though I think the author is unaware that T-Mobile exists in other countries beside the US, and the wikipedia links are not totally clear if the block applies to all of T-Mobile or just the part they say is difficult to deal with (T-Mobile USA). Presumably just T-Mobile USA???
Solutions
Create an account
Blocks on T-Mobile IPv6 servers are set to "anon. only" (sometimes abbreviated as "AO" or "AB") meaning only registered users who have logged in can edit from this IP address. If you are currently blocked from creating an account, we suggest the following:
Create an account on a desktop or laptop computer and then log in with your phone.
Ask a trusted friend on a different network to create an account for you. You may use Wikipedia:Request an account.
Try again after the block on your IP address expires. Go to my contributions and follow the Block log link at the top of the page to find the length of the block.
See Why create an account? for a full list of benefits that come with registration.
Bypass T-Mobile's IPv6 servers
The easiest solution to avoid being blocked from editing Wikipedia while using T-Mobile is to bypass their servers altogether. By connecting to the Wikipedia servers from your desktop or laptop computer (or from your WiFi), the IP address that Wikipedia's server will see is one that is owned by your desktop ISP, rather than that of T-Mobile.
Instead of editing Wikipedia using the T-Mobile cellular connection, try using your WiFi connection. (This is increasingly a false dichotomy. T-Mobile is pushing into the home internet market with 5G cellular—to the tune of more than 640k US households at the close of 2021.)
Use a desktop or laptop, or WiFi only tablet computer. These computers are most likely not using T-Mobile, and therefore, do not route traffic through T-Mobile servers.
Autoblocked
If you have already logged into an account and your block message reads "Autoblocked because your IP address has been recently used by" followed by a username, or your block log (check via the Block log link at the top of your "my contributions" page) does not list any current blocks, then you have been autoblocked. Please go back to your blocked page and follow the instructions under the Autoblocked? section or alternatively here.
Minecraft has a couple of different ways that crafting is done:
1) the original way where you have a grid that you can put items/crafting materials on. If you put particular materials on the grid in the pattern for an item, it will give you the option of taking that item at the expense of the ingrediants
2) when they ported to consoles, they made it with a recipe book, where you choose what you want to make and creation just happens if you can - no need to remember patterns, no need to move items into the pattern. The recipe book shows things that you have some of the ingredients of, and has colour coded backgrounds for all the ingredients or just some.
Either way you craft things that the game already knows about. Building things in the world is different - you just place blocks or items where you want them. I'm not sure how that relates to programming. I can't say I really understood the article.
So in a way, if you go through all the work of setting that up you should be rewarded with some sort of crafting. After all, the type checker is kinda doing some of that work anyway
So there is quite a stir about dependent types in academia these days
Remember that coming up w the names for types is half the battle. Whether something is a "string" or an "Address" or an "InputField" is really a multi-dimensional type problem
Playing around with this, seems I created a new channel/room/page called "raar" (https://coffeehouse.chat/raar), I wasn't expecting it to just let me create something that seems to be just there on the homepage as literally the second channel, without any signup or anything. It also seems to be a public thing. I opened the link on my phone and joined the call from there and it connected. However when I tried again it wouldn't connect
Just had my first actual proper call, with a guy in Turkey who seemed very nice, call worked really well. In part of the conversation he asked about what I was working on, and I missed the ability to send a link through the call - (though maybe that's a sign that my own domain could have a better name!)
I wouldn't say your UI is bad - it's certainly a reasonable MVP at this point. You could probably stick ads on it or a newsletter sign up on it for people interested in it. If I wasn't looking for UI improvements to point out, first glance would be it's pretty good, and what I'd expect - I certainly wouldn't immediately bounce - though the input boxes do need to support splitting ingredients by typing a comma - typing enter is not instinctive and even once I'd figured that out, when going again I "messed up". I listed ingredients as I'd expect to for an input box, and when I moved to the next box my input was lost.
It sounds like you need to spend time using it yourself, thinking over it's use, getting others to use it, watching them get stuck, listening to their questions. Get family or friends who have never used the app to use it while you are there and find out what they struggle with. For knowing what functionality it needs - find people who are interested in paying for that kind of product - family and friends are great for doing the app equivalent of proofreading, but unless they are in your market they may well have lots of ideas, but you'll have no idea if they're the right ideas to build.
Some confusing things about your UI (in order of me noticing them):
- "Are there any ingredients that are not available?" - this looks like it needs rewording to something like "avoid these ingredients" or "any common ingredients not available", I knew what you meant, the search will exclude recipes with those items, but it felt weird to read - there are probably 1000s of ingredients that I don't have in my kitchen, I'm not going list those. I might list things like milk if I where cooking for a lactose intolerant person in that box, or I might use that for if I where out of something common.
- on laptop screen, box around the search form has a huge gap to the right of the form inputs. I'd either make the inputs a % width of that box, or put them in two columns when wide enough
- the previously mentioned thing about inputs needing to treat , being entered as if the user had tapped space
- I'd probably expect to see filters for vegan/veggie/pescatarian / low gi etc but then maybe not - that's the kind of thing you could build if you run out of things from proper users - unfortunately I rarely cook proper meals so I'm not really in your target market I would assume.
- Shopping list feature is a feature I could use, if it where better, (though I currently use a shopping list app that I threw together myself by quickly modifying another thing I'd made previously, and it works reasonably well for me) - your icons seem too small and fiddly, and I'd want a few buttons on screen of common things - so I can tap those instead of typing them.
> "Are there any ingredients that are not available?" ... I knew what you meant, the search will exclude recipes with those items, but it felt weird to read
That makes sense too. If I remember correctly, that prompt was most-recently rephrased during a pandemic-related lockdown (with subsequent unpredictable ingredient shortages), and so that context may have affected the choice of wording; either way, I agree that it's odd phrasing and should be updated.
Hopefully that'll be a relatively quick correction, although it will require internationalization (currently machine-translated without review by native language speakers, not ideal); it's filed as https://github.com/openculinary/internationalization/issues/...
> box around the search form has a huge gap to the right of the form inputs
> I'd probably expect to see filters for vegan/veggie/pescatarian / low gi etc but then maybe not
Two good points here, and possibly combinable. Perhaps those dietary recipe filters could be placed in the excess space available next to the search controls.
Today the search API does theoretically support filtering[1] on a few dietary properties -- but that functionality isn't yet visible and available to the user.
- Shopping list feature ... your icons seem too small and fiddly, and I'd want a few buttons on screen of common things - so I can tap those instead of typing
The frequently-added-items shortcut idea is smart. The shopping list feature and the meal planner are under-attended components of the app relative to the recipe search/explore components, in my opinion. Let me think about this for a while, there are a few considerations and I'd like to be concise when responding about this in more detail.
Hey - if you re-read recent threads and see this reply, great; and no worries if not - thanks for your feedback, in either case.
All I'll say for now is that arguably the shopping list should become an important nexus within the app. Like an accounting entry-book with both order history and also yet-to-be-filled orders, it could be used to approximate the kitchen inventory at points-in-time. That should become powerful when changes in inventory are used to feed back into current and future meal planning.
Separately: advice noted about testing with friends and family. My partner and I use the app at home once or twice a week, and following recent improvements it's probably time to reach out for more feedback from others.
I find maintaining a balance between asking for (re)evaluation of the app and a hope for regular everyday conversations a little tricky; but to be honest I've always found the latter challenging, probably.
