|
Ham, a thin slice, wrap the pill, dogs tend to swallow whole, worked like a charm for me. Best of luck with your pup.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
What I have found with our Aussie Cattle Dog (Extremely smart) that if I wrap half a pill at a time in soft cheese, Velvetta(I know questionable on if it is cheese but it tastes good) and I make sure that he is looking up at me as I give it to him. Then I gently hold his nose higher than the rest of his head. He swallows no problem and doesn't fight or anything.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Slice of cheese cut into 8 micro slices does the trick for us.
Must totally seal the pill. One person seals it, someone different delivers it so the pet cannot smell the medicine on your fingers.
The pup can smell a squirrel at 200 meters, you think it won’t notice the medicine dust on your fingers!
|
|
|
|
|
My sister makes a bread ball and makes a show of eating a bite of bread.
When she accidentally on purpose drops the medicine bread ball, the dog snatches it.
|
|
|
|
|
Try using a device called a pill shooter. It's a slender tube with a plunger inside and an open end. You stick the tube inside the dog's mouth and press the plunger, and the pill is projected far back on his tongue so he must swallow it.
I used this device with my cat several times and it works.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
much deleted hope the dog is better, happy you can pay the happier vet
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Good luck to Grizzly! Glad to hear he has a good human.
|
|
|
|
|
Last friday my 9 year old lab that I made fat had left rear passenger side TPLO ACL surgery. That's where they put a metal plate in blah blah etc etc. Supposed to last. She has been having to stay down at the shop with me where there is no furniture to jump up on. At home we are both "quarantined" in the spare bedroom to keep her off her beloved sofa. Tomorrow we see the vet surgeon man to see how she is coming along.
I'm hoping I can soon walk her a little as she is looking at me like so.... this is my life now no walks, (carrots for scoobie snacks) jerk face? 
Best of blessings to you and your pooch. 
|
|
|
|
|
An alternative to the cone is to cut up a pool noodle and string it around the neck (3 weeks after elbow surgery), slightly less intrusive than the cone and won't catch every door frame in the house.
Ah Labradors, they will eat anything so pills are a non issue.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Crush the pills and add them to cheese slices. That works for Max, 3 years old Pekingese male. Can't force him to swallow anything; he will bite.
|
|
|
|
|
Looking for guidance for someone else.
Anyone here experience with UI/UX designing? I was wondering how can one start with this. Specially someone who has absolutely no knowledge of computer programming or even operating them in general. I can find tons of online resource each claiming they are the best and I have no way to choose a good one.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
|
|
UI/UX "designing" is arcane magic.
The following rules apply:
1. Recognize that you haven't a clue what the user actually wants. Learn what their standard processes are (when things go smoothly) and learn what they do when things don't go smoothly. The UI/UX must handle the latter.
2. Recognize that the user doesn't have a clue either, because they are stuck in their old (often paper, yes still in this age) workflows and want the UI/UX to replicate their existing workflows which is so wrong for a UI.
3. Identify the vital (buzzword: "mission critical") information that must be present
4. Research how the users actually need that information visualized. Managers want pretty graphs, the clerk wants numbers and text.
5. Don't hide things behind context menus or other right-click processes. People should be able to see what their options are. Read the thread below about the context menu in W11.
6. Anticipate stupidity. We had a customer call customer support to ask "where is the 'any' key" just a couple days ago because of the message "Press any key to continue." I kid you not.
7. A UX needs to accommodate helping the user, step by step, go through a workflow, as well as the expert user that doesn't need hand-holding.
8. A UI needs to accommodate nuances in the data, including no data, large data, small and large values (particularly when dealing with text), formatting, etc.
9. Everything, and I mean EVERYTHING, should be validated on the front-end with informative messages as to why the "inputs" are wrong and how to fix them.
10. Don't write the application in VB. I can tell a VB application instantly because VB programmers love to make their UI look like a Disneyland flowerbed.
11. Bonus: Make the UI/UX as configurable with metadata as possible. Ideally consider that the goal is that each user can customize the UI/UX for their individual skill level and needs.
That should get you started. 
|
|
|
|
|
Sounds a lot like the discussion I had with her before posting.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
No no no number 11 is a horror of the first degree!
Bild in a configurable UI
User 1 changes every possible option.
User 1 quits/gets promoted/sacked or just moves on
User 2 bitches to you the developer that nothing matches the doco
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
Keep a "Reset UI" functionality at hand at all times. Some IDEs have it, gods bless them.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Good answer and I largely agree, but have a few differences in opinion. First, who are you designing for? "Expert Systems" are a different breed than general public. It modifies some of your points if you are designing expert systems.
For example:
#2 The UI/UX is wrapped around the process/workflow. We may not like it, and may be able to create a better UX, but often the processes are a requirement of the design. There's a chance you can improve workflows, but not unusual to be stuck with it.
#5 Again, context menus can be very effective in a business system. The only need is to know what should be in them and also have an alternative available.
#7 This is highly variable depending on the design case. I've sat next to users having to click through seven screens, due to a forced workflow, for something that should have been one-click.
#10 I'd venture that is experience rather than IDE choice. I can create bad UIs in any language, lol. Good ones as well.
I'd also tack on "don't do it because you can". It might be more of a web UI thing, but I've seen some very impractical uses of technology that take away from the UX. And work both top down and bottom up unless you are starting from scratch. Often, the data IS the data, period.
|
|
|
|
|
"Press any key" was dangerous, and now even more dangerous. Even with power keys died off from the keyboards.
Users love corner keys like ctrl, shift, esc, to name a few. Then the local menu key. Then the F keys. Now they are often worse than F keys on new laptops.
|
|
|
|
|
Somehow, I often end up with customers who say to me, "I won't know what I want until I see it." How the heck are you supposed to deal with that? Well, there are many options one could take. When possible I choose the option where I make everything configurable and adjust it until they are happy or until I am tired of it, which ever comes first. Sometimes I tire quickly and tell the customer, "here you go - you can do what ever you want with it," and let them deal with it. They usually get much more accommodating when I tell them to do it themself.
That approach is often not an available option and when it isn't I find it is best to make things a flexible as you can possibly make them so you make changes quickly. That is, if you are so inclined. Sometimes I have no patience and just say, "here it is and you are going to like it. Or not. Regardless, here it is."
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Good, old Itsy Bitsy Machines had the opposite problem a generation ago:
They had developed a super-great UI prototyping system (written in APL!). The salesman could sit in a dialog with a customer, and modify the UI there, on the spot, to the customer's wishes, and the customer could take the UI prototype home to present to his co-workers/co-users. Setting up stub functions to deliver/accept data was trivial: The prototype could display not just static screen dumps, but a lot of dynamic behavior as well.
The problem was that the prototypes were so complete that the customer said: "This is great. I'll take it!", not fully realizing that it was a mock-up, of nothing like production quality, and with functional stubs. So the IBM salespeople had to learn to make incomplete mock-ups, to keep customers from running away with the prototype, not wanting to pay for development of the production version.
My approach to your problem: UI development is not me telling a customer how I think that his problem can be solved. It is him telling me how he sees his problem. Not the solution, but the problem. What does he see as elements of the problem, how they relate. How his work procedures are. Have him teach me his professional terminology. I write down my understanding of everything he explains to me, and let him correct and augment my notes.
Then I go home and make a very first UI prototype, modeled after the customer's concepts, established terminology and work methods - obviously following UI platform standards. Before the customer gets to try the prototype, I can explain to him - on a whiteboard, not in computer terms - the way I have been thinking to solve his problem, how I group data, what operations should be provided and which effect they will have on different data groups. Maybe the user has so many objections that I have to go back and change the conceptual solution before showing any UI prototype makes sense. When the customer has agreed to a conceptual solution outline, the feedback on a UI prototype is usually quite productive.
My impression is that software developers should spend far more time, especially in the early project phases, listening to the customer's view on the problem and possible solutions, and certainly not just for politeness, but in order to get to know the problem domain, understand the customer's viewpoint. We are much more eager to focus on our domain, rather than the problem domain. Start by listening. Agree on a conceptual problem solution. Then design a UI according to that.
|
|
|
|
|
This is what I started on, more or less:
https://www.amazon.ca/About-Face-Essentials-Interaction-Design/dp/1118766571
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Programming & UX are two different topics. My company works with a design bureau right now. The guys I'm talking to (I'm the programmer in this equation) got literally no idea about anything programming (except HTML, but that's not a programming language, they don't even work in it, merely export in it) but they're really great at what they're doing, namely UX design.
So are you talking about programming or about UX design?
|
|
|
|
|
That sounds awkward to me. You really need an SA that can look at both sides. In many cases, the data and needed workflows have to drive the UI to create the UX. My preference is bottom up while keeping the top-down in my thoughts at all times. Then turn it over to the make pretty group and tell them if they touch the code flow, I'll break their fingers. Not really of course, but work together to come up with the best UX possible given the required criteria. It's an agile give and take through the entire development track.
|
|
|
|
|
Very much true, the work-/dataflow has to drive the UI. That's why we're designing the UX according to the workflow while I (the dev) sit in the meeting, making sure my backend fulfills the use case requirements (work-/dataflow) and answer questions in the likes of "can we do that". When you're designing for end-users, that's a hella great methodic.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
